Clash 초보자 FAQ 10가지: 혼합 포트·전역 모드·구독 업데이트·규칙 정리

1. Clash 클라이언트와 코어는 무엇이 다른가요?

클라이언트는 화면 표시, 구독 관리, 시스템 프록시 설정, 실행 상태 확인을 담당합니다. 코어는 설정 파일을 읽고 규칙을 적용하며, 도메인을 확인하고 연결을 설정합니다. 클라이언트를 설치했다고 해서 사용할 프록시 노드까지 준비된 것은 아닙니다. 연결하려면 유효한 설정, 접속 가능한 노드, 올바른 트래픽 전달 방식이 필요합니다.

Clash Meta는 이후 mihomo라는 이름으로 계속 개발되고 있습니다. 코어마다 지원하는 프로토콜, DNS 필드, 규칙 유형이 다를 수 있습니다. ‘Clash 설정 지원’이 모든 설정 파일의 완벽한 호환을 뜻하지는 않습니다. 가져오는 과정에서 ‘알 수 없는 프록시 유형’ 또는 ‘지원하지 않는 필드’ 오류가 나오면 노드 비밀번호를 계속 바꾸기보다 먼저 코어를 확인하세요.

확인 위치: 클라이언트의 ‘설정’ → ‘정보’ 또는 ‘코어’ 페이지에서 클라이언트 버전과 코어 버전을 각각 확인해 기록하세요.
오류 확인: ‘로그’를 열고 시작 시 표시되는 코어 이름, 설정 로드 결과, 오류 필드를 확인하세요.
선택 기준: 먼저 서비스 제공업체가 요구하는 프로토콜과 코어를 확인한 뒤, 클라이언트 비교 페이지에서 적합한 제품을 고르세요.

2. 혼합 포트란 무엇이며 7890은 어디에 입력하나요?

mixed-port는 로컬 프록시가 요청을 받는 포트입니다. 하나의 포트에서 HTTP 프록시와 SOCKS 프록시 요청을 모두 처리합니다. 7890은 흔히 쓰이는 예시일 뿐, 고정 규격도 원격 노드의 포트도 아닙니다. 실제 포트는 클라이언트의 ‘설정’ → ‘포트’에서 확인하세요. 일부 클라이언트에서는 ‘코어 설정’에 있습니다.

항목	예시 값	입력 위치
로컬 프록시 주소	`127.0.0.1`	브라우저 또는 앱의 프록시 서버 주소
혼합 포트	`7890`	앱에서 사용할 HTTP 또는 SOCKS 프록시 포트
원격 노드 포트	설정 파일에 지정된 값	노드 설정에 사용하며 로컬 포트로 바꾸지 않음
컨트롤러 포트	현재 설정 파일의 값 사용	관리 패널이 코어에 연결할 때 사용하며 웹 프록시에는 사용하지 않음

아래는 로컬 수신 설정 예시이며, 노드 설정을 포함한 전체 설정 파일이 아닙니다. 이 기기에서만 사용할 경우 루프백 주소에 바인딩하고, 로컬 네트워크 접근은 꺼 두세요.

mixed-port: 7890
allow-lan: false
bind-address: '127.0.0.1'
mode: rule

로그에 address already in use가 표시되면 보통 다른 프로세스가 해당 포트를 사용 중이라는 뜻입니다. 먼저 중복 실행된 클라이언트를 종료하고 포트 사용 여부를 확인하세요. 꼭 7891로 변경해야 한다면 앱의 수동 프록시 주소도 함께 바꿔야 합니다. 화면의 포트만 바꾸고 앱에 이전 포트가 남아 있으면 연결이 거부됩니다.

3. 규칙·전역·직접 연결 모드, 어떻게 선택하나요?

세 모드는 트래픽이 코어에 들어온 뒤 어떤 방식으로 외부에 연결할지 결정합니다. 모든 앱의 트래픽을 자동으로 코어에 전달하는 기능은 아닙니다. 전역 모드로 바꿔도 시스템 프록시를 따르지 않는 터미널이 자동으로 프록시를 사용하지는 않습니다.

규칙 모드(Rule): 설정에 있는 규칙에 따라 직접 연결, 차단 또는 프록시 그룹을 선택합니다. 일반적인 사용은 이 모드부터 시작하세요.
전역 모드(Global): 코어에 들어온 일반 연결을 전역 선택 항목으로 처리합니다. ‘프록시’ → ‘GLOBAL’에서 실제 선택 항목을 확인해야 하며, 모드 스위치만 확인해서는 안 됩니다.
직접 연결 모드(Direct): 코어에 들어온 연결은 보통 원격 프록시 노드를 거치지 않고 바로 외부로 연결됩니다.

설정 위치: ‘프록시’ 또는 ‘대시보드’ → ‘아웃바운드 모드’에서 ‘규칙’을 선택한 다음, 대상 프록시 그룹에서 사용할 수 있는 노드를 선택하세요. 코어마다 DNS나 라우팅 동작이 별도로 적용될 수 있으므로, 전역 모드가 ‘시스템의 모든 트래픽이 하나의 노드를 거친다’는 보장은 아닙니다.

특정 사이트에 문제가 있을 때는 잠시 전역 모드로 바꿔 비교해 보세요. 전역 모드에서는 되지만 규칙 모드에서는 안 된다면 적용된 규칙과 프록시 그룹을 확인하세요. 두 모드 모두 실패한다면 노드, DNS, 트래픽이 코어로 들어오는지 차례로 점검하세요.

4. 구독 링크, 설정 파일, 노드는 어떻게 다른가요?

노드는 원격으로 연결하기 위한 서버 주소, 포트, 프로토콜, 인증 정보의 묶음입니다. 설정 파일에는 노드뿐 아니라 프록시 그룹, 규칙, DNS 설정도 포함될 수 있습니다. 구독 링크는 이러한 정보를 가져오는 주소로, 전체 YAML 설정 파일을 반환할 수도 있고 노드 목록만 반환할 수도 있습니다.

제공받은 항목에 맞는 가져오기 방법

현재 클라이언트에 맞는 구독 주소를 받은 다음 ‘설정’ → ‘새로 만들기’ → ‘URL 가져오기’를 열어 붙여넣고 다운로드하세요.
로컬 YAML 파일을 받은 경우에는 ‘설정’ → ‘파일 가져오기’를 사용하세요. 파일 내용을 URL 입력란에 붙여넣지 마세요.
다운로드가 끝나면 해당 설정을 선택해 현재 사용 중인 항목으로 표시되는지 확인한 뒤, ‘프록시’ 페이지에 원하는 프록시 그룹이 표시되는지 살펴보세요.

일부 클라이언트는 단일 노드 링크 가져오기를 지원하지만, 이 링크에 규칙 기반 분기 설정까지 포함되어 있다는 뜻은 아닙니다. 노드만 있는 경우 프록시 그룹과 규칙을 채우기 위해 클라이언트 설정 템플릿이 추가로 필요할 수 있습니다. ‘가져오기는 성공했는데 프록시 그룹이 없음’ 오류가 발생하면 먼저 가져온 콘텐츠 유형을 확인하세요.

5. 구독은 얼마나 자주 업데이트하나요? 수동 변경 사항도 덮어쓰나요?

구독 업데이트는 설정을 다시 가져오는 기능이지, 클라이언트 업그레이드나 노드 지연 시간 측정이 아닙니다. 업데이트 주기는 서비스 제공업체의 변경 일정에 따라 달라집니다. 우선 24시간 간격으로 설정하고, 제공업체가 다른 주기를 안내했다면 그에 맞게 조정하세요. 연속으로 업데이트 버튼을 눌러도 만료된 링크나 호환되지 않는 형식 문제는 해결되지 않습니다.

설정 위치: ‘설정’ → 현재 구독의 메뉴 → ‘업데이트’ 또는 ‘편집’ → ‘업데이트 간격’. 단위를 확인하세요. 초 단위라면 24시간은 86400, 분 단위라면 1440입니다. 일부 클라이언트는 종료 중에 예약 작업을 실행하지 않습니다. 이를 근거로 서버 업데이트가 중단됐다고 판단하지 마세요.

수동 업데이트 시점: 제공업체에서 변경 사항을 알렸거나, 노드 다수가 작동하지 않거나, 설정 내용이 눈에 띄게 오래된 경우입니다.
덮어써질 수 있는 항목: 다운로드한 설정 파일에 직접 입력한 규칙, 노드 이름, DNS 매개변수입니다.
사용자 설정 유지: 수정 전에 사본을 저장하고, 클라이언트가 지원하는 오버라이드, 병합 또는 확장 설정 기능을 우선 사용하세요.

‘업데이트 성공’은 이번 다운로드와 로드 과정이 완료됐다는 뜻일 뿐, 모든 노드의 연결 가능성을 보장하지 않습니다. 다운로드에 실패했다면 먼저 로그의 HTTP 상태 코드와 파싱 정보를 확인하세요. 401·403은 권한이나 접근 정책, 404는 주소 만료와 관련이 있을 수 있습니다. 파싱 오류가 나면 응답 내용이 실제 설정 파일인지 확인하세요.

6. 규칙은 어떻게 적용되며 순서가 결과에 영향을 주는 이유는 무엇인가요?

일반 규칙 목록은 위에서 아래 순서로 확인되며, 일치하는 규칙을 찾으면 해당 규칙에 지정된 아웃바운드를 사용합니다. 구체적인 예외 규칙은 위쪽에, 마지막에 적용되는 기본 규칙은 맨 아래에 둡니다. 아래 예시는 문서용 예약 도메인을 사용하므로 실제 구독에 있는 프록시 그룹 이름과 관계가 없습니다.

rules:
  - DOMAIN,login.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,DIRECT

DOMAIN은 도메인 전체와 일치하고, DOMAIN-SUFFIX는 해당 도메인과 하위 도메인에 일치합니다. GEOIP,CN은 대상 IP의 지리 데이터베이스상 위치를 기준으로 일치하며, MATCH는 기본 규칙입니다. 위 예시는 순서를 설명하기 위한 것으로 모두 직접 연결합니다. 프록시 그룹을 지정하려면 아웃바운드 이름을 설정 파일에 실제로 존재하는 그룹 이름으로 바꾸고, 이름을 정확히 일치시켜야 합니다.

확인 위치: ‘연결’에서 해당 요청을 찾아 적용된 규칙, 규칙 페이로드, 아웃바운드 체인을 확인하세요. 일부 클라이언트에서는 상세 정보를 펼쳐야 합니다. 적용된 규칙이 화면에 표시되지 않는다면 ‘설정’ → ‘로그 수준’에서 잠시 더 자세한 수준을 선택해 한 번 재현한 다음 원래대로 돌리세요. 연결 정보가 장기간 과도하게 기록되지 않도록 주의하세요.

도메인 규칙을 적용하려면 코어가 도메인 정보를 확인할 수 있어야 합니다. 앱이 IP 주소로 직접 연결하거나 DNS 처리 방식이 다르거나 기존 연결이 아직 닫히지 않은 경우, 규칙 문구만 보고 예상한 결과와 다를 수 있습니다. 규칙을 수정한 뒤에는 새 연결을 만들어 확인하세요.

7. 시스템 프록시와 TUN 모드는 어떻게 다른가요?

시스템 프록시는 이 기기의 프록시 주소를 운영체제 설정에 등록하는 방식으로, 해당 설정을 따르는 브라우저와 앱에 적합합니다. TUN 모드는 가상 네트워크 인터페이스와 라우팅으로 트래픽을 전달해 시스템 프록시를 따르지 않는 일부 앱도 처리할 수 있습니다. 다만 라우팅, 제외 항목, 권한, 플랫폼별 구현에 따라 적용 범위가 달라집니다.

데스크톱에서 시작하는 순서

먼저 클라이언트의 ‘설정’이나 트레이 메뉴에서 ‘시스템 프록시’를 켜고, 브라우저가 연결되는지 확인하세요.
대상 앱이 여전히 ‘연결’ 목록에 나타나지 않으면 앱 자체에 별도의 프록시 설정이 있는지 확인하세요.
더 많은 트래픽을 전달해야 한다면 클라이언트 안내에 따라 서비스를 설치하거나 권한을 부여한 다음 ‘TUN 모드’를 켜세요.

Windows에서는 관리자 권한이나 서비스 모드가 필요한 경우가 많고, macOS에서는 관련 시스템 권한을 승인해야 할 수 있습니다. Android와 iOS 클라이언트는 보통 시스템 VPN 인터페이스로 트래픽을 전달하므로 데스크톱의 시스템 프록시 설정 절차를 그대로 적용할 수 없습니다. 다른 VPN, 가상 네트워크 인터페이스 도구, 분할 터널링 소프트웨어를 동시에 실행하면 라우팅 충돌이 발생할 수 있습니다.

초보자는 한 번의 문제 해결 과정에서 TUN, DNS, 규칙을 동시에 변경하지 않는 것이 좋습니다. 한 번에 하나씩 바꾸고, 켜고 끈 상태의 차이를 기록하세요. TUN을 켠 뒤 네트워크에 문제가 생기면 먼저 TUN을 꺼서 복구한 다음 권한, 라우팅 충돌, DNS 처리 여부를 차례로 확인하세요.

8. 브라우저는 되는데 터미널은 왜 연결되지 않나요?

많은 명령줄 프로그램은 데스크톱 시스템 프록시 설정을 읽지 않습니다. http_proxy, https_proxy 같은 환경 변수를 읽거나 자체 프록시 옵션만 인식할 수 있습니다. 브라우저 연결 성공은 브라우저의 현재 경로가 작동한다는 뜻일 뿐, 터미널도 같은 경로를 사용한다는 뜻은 아닙니다.

설정 위치: 먼저 클라이언트의 ‘설정’ → ‘포트’에서 실제 혼합 포트를 확인한 뒤 터미널에서 프록시를 명시해 요청을 보내세요. 127.0.0.1:7890에서 수신 중인 경우:

# macOS / Linux
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --head https://example.com

# Windows PowerShell
curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --head https://example.com

Windows에서는 curl.exe를 사용하면 일부 PowerShell 환경에서 curl이 다른 명령으로 해석되는 문제를 피할 수 있습니다. 대상 사이트의 HTTP 응답을 받았다면 이번 요청에 응답이 도착한 것입니다. 로컬 포트 연결에 실패했다는 메시지가 나오면 클라이언트 실행 여부와 포트가 일치하는지 먼저 확인하세요.

현재 macOS 또는 Linux 셸에 변수를 임시로 설정하려면 아래 명령을 사용할 수 있습니다. HTTPS 사이트도 HTTP 프록시의 CONNECT 터널을 통해 접속하므로 프록시 주소에는 http://를 사용합니다.

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890

# 문제 해결이 끝나면 현재 셸의 설정을 지우세요
unset http_proxy https_proxy

이 변수는 해당 변수를 지원하는 프로그램과 그 프로세스 환경에만 적용됩니다. 변수를 설정했는데도 직접 연결된다면 프로그램 자체 설정과 no_proxy 예외 항목을 확인하세요. 전역 모드를 터미널 프록시 설정의 대안으로 사용하지 마세요.

9. 노드 지연 시간은 낮은데 다운로드가 느린 이유는 무엇인가요?

클라이언트에 표시되는 지연 시간은 보통 연결 테스트나 HTTP 탐색 결과이며, 구체적인 측정 방식은 클라이언트와 설정에 따라 다릅니다. 다운로드 속도와 같지 않으며 ICMP ping 결과가 아닐 수도 있습니다. 지연 시간이 40ms로 표시되는 노드도 지속적인 전송에서는 회선 혼잡, 서버 대역폭, 대상 사이트의 정책 때문에 속도가 제한될 수 있습니다.

설정 위치: ‘프록시’ → 대상 프록시 그룹에서 ‘지연 시간 테스트’를 실행하고 테스트 URL, 시간, 시간 초과 설정을 기록하세요. 노드를 바꾼 뒤에는 기존 다운로드를 종료하고 새 연결을 만드세요. 이미 맺어진 TCP 연결은 프록시 그룹을 바꿔도 보통 즉시 다른 경로로 이동하지 않습니다.

지연 시간 비교: 동일한 테스트 URL로 연속 3회 측정하세요. 한 번의 결과만으로 안정성을 판단하지 마세요.
전송 속도 비교: 동일한 다운로드 소스와 파일을 사용해 약 30초 동안의 지속 속도를 확인하고, ‘연결’에서 선택된 아웃바운드도 함께 확인하세요.
단위 환산: 8 Mbps는 이론상 약 1 MB/s이며, 프로토콜 오버헤드는 반영하지 않은 값입니다. 두 단위를 그대로 비교하지 마세요.

예를 들어 50ms라는 표시로 알 수 있는 것은 해당 측정 결과뿐이며, 50MB/s 속도를 낼 수 있다는 뜻은 아닙니다. 특정 사이트만 느리다면 해당 사이트의 연결과 트래픽 분기 설정을 먼저 확인하세요. 모든 노드가 느리다면 로컬 네트워크, 다른 기기, 시간대별 결과를 비교하세요. 여기에 나온 수치는 설명을 위한 예시이며 실제 노드의 성능을 보장하지 않습니다.

10. 가져온 뒤에도 인터넷에 연결되지 않을 때 먼저 확인할 항목

‘설정 로드 → 로컬 포트 수신 → 트래픽 유입 → 규칙에 따른 아웃바운드 선택 → 원격 연결’ 순서로 점검하세요. 구독, 포트, DNS를 한꺼번에 바꾸기보다 먼저 실패하는 단계를 찾으면 문제를 재현하기 쉽습니다.

설정 파일 확인: ‘설정’에서 현재 항목이 선택되어 있는지, 로그에 YAML 파싱 오류가 없는지 확인하세요. YAML은 공백으로 들여쓰고 같은 수준의 필드는 정렬해야 하며 Tab은 사용할 수 없습니다.
포트 수신 확인: ‘설정’에서 포트를 확인하고 프록시를 명시한 명령으로 한 번 접속해 보세요. 이전 프로세스와 포트 충돌도 점검하세요.
트래픽 유입 확인: ‘연결’을 열고 대상에 다시 접속하세요. 새 연결이 표시되지 않으면 시스템 프록시, 앱 자체 프록시, TUN 연결을 확인하세요.
규칙 확인: 연결이 표시되면 상세 정보를 열어 예상한 규칙이 적용됐는지, 사용할 수 있는 프록시 그룹이 선택됐는지 확인하세요.
오류 유형 확인: 이름 확인 오류는 DNS를, 연결 시간 초과는 노드 접속 가능 여부를, 인증 실패는 인증 정보나 구독 상태를 먼저 확인하세요.
원상 복구 확인: 클라이언트를 잠시 종료하기 전에 시스템 프록시를 끄세요. 클라이언트의 시스템 프록시만 끄고 업무 네트워크에 필요한 기업용 설정은 삭제하지 마세요.

도움을 요청할 때는 운영체제, 클라이언트 및 코어 버전, 발생 시간, 문제가 생긴 앱, 민감 정보를 가린 로그를 함께 제공하세요. ‘브라우저는 되지만 터미널은 안 됨’ 또는 ‘프록시를 명시해도 로컬 포트 연결 실패’처럼 구체적으로 설명하면 ‘인터넷이 안 됨’만 적는 것보다 원인을 찾기 쉽습니다. 플랫폼별 권한과 설치 순서는 설치 가이드에서, 개념과 자주 묻는 설정은 FAQ에서 확인하세요.