Clash 설정 가이드: 구독 가져오기부터 적용 확인까지

Clash 클라이언트 자체에는 회선이 포함되어 있지 않습니다. 사용할 수 있는 노드는 모두 구독 설정에서 오기 때문에 설정의 첫 단계는 언제나 구독 가져오기입니다. 구독 링크는 서비스 제공자가 생성하며 https://sub.example.com/api/v1/client/subscribe?token=xxxx 형태입니다. 링크 하나가 프록시 노드, 정책 그룹, 분기 규칙 세 부분을 담은 완전한 YAML 파일을 반환합니다. 가져오기 전에 링크를 빠짐없이 복사하세요. 가져오기 실패의 대부분은 클라이언트 문제가 아니라 메신저나 메일에서 링크가 잘려 끝의 token 파라미터가 몇 자 빠진 상태로 전달되기 때문이며, 이 경우 클라이언트는 유효하지 않은 응답을 받게 됩니다.

각 클라이언트의 가져오기 경로는 다음과 같습니다.

• Clash Verge Rev(Windows / macOS / Linux): 왼쪽 사이드바에서 「구독」을 누르고 상단 입력란에 링크를 붙여 넣은 뒤 Enter를 누르거나 「가져오기」를 클릭합니다. 클라이언트는 곧바로 구독 주소로 요청을 한 번 보냅니다.
• Clash Plus(Windows / macOS / Android / iOS): 메인 화면에서 「구독」 그룹으로 들어가 오른쪽 위 「구독 추가」를 누르고 링크를 붙여 넣은 뒤 확인합니다. 모바일에서는 처음에 네트워크 권한을 요청하며, 허용해야 설정 파일을 실제로 내려받습니다.
• Clash Meta for Android: 왼쪽 드로어에서 「구성」으로 들어가 오른쪽 아래 + 버튼을 누르고 「URL에서 가져오기」를 선택한 뒤 링크를 붙여 넣고 구분하기 쉬운 이름을 지정합니다.
• ClashX Meta(macOS): 메뉴 막대 아이콘 → 「구성」 → 「관리형 구성」 → 「관리」를 누르고, 창에서 Add를 눌러 URL 칸에 링크를 붙여 넣은 뒤 확인하고 메뉴로 돌아와 이 구성을 선택합니다.

가져오기 성공은 세 가지로 확인합니다. 설정 목록에 새 항목이 생기고, 항목을 펼쳤을 때 노드나 정책 그룹이 보이며, 파싱 오류 팝업이 뜨지 않아야 합니다. 세 가지가 모두 충족되면 다음 단계로 넘어갑니다. 「구성 파싱 실패」가 뜨거나 목록이 계속 비어 있다면 먼저 브라우저에서 구독 링크를 직접 열어 보세요. YAML 텍스트가 반환되면 링크 자체는 정상이고 문제는 클라이언트 버전에 있습니다. base64 문자열이나 웹페이지가 반환되면 서비스 측이 범용 형식으로 출력하고 있거나 링크가 만료된 것이므로, 서비스 관리 페이지에서 Clash 형식으로 바꾼 뒤 다시 복사해야 합니다.

가져오기가 끝나면 자동 업데이트도 함께 켜 두는 것을 권합니다. 구독에 포함된 노드는 수시로 교체되므로 클라이언트 목록의 구성을 갱신하지 않으면 며칠 뒤 전체가 타임아웃될 수 있습니다. Clash Verge Rev는 구성 항목의 오른쪽 클릭 메뉴에서 업데이트 간격을 설정하고, Clash Plus는 구독 상세 페이지에서 설정합니다. 24시간을 권장합니다. 수동 업데이트도 같은 메뉴나 상세 페이지에서 할 수 있으며, 노드가 대거 먹통이 되면 다른 원인을 찾기 전에 구독을 한 번 갱신하세요.

설정을 가져오면 클라이언트 안에는 노드, 정책 그룹, 규칙 세 가지가 함께 존재합니다. 트래픽이 어디로 갈지 결정하는 스위치가 프록시 모드이며, 주요 클라이언트는 네 가지 선택지를 제공합니다.

• 규칙 모드(rule): 기본값이자 평소에 유지해야 하는 모드입니다. 클라이언트가 설정의 rules 섹션을 위에서 아래로 순서대로 매칭하고, 걸린 규칙이 가리키는 정책 그룹으로 처리를 넘깁니다. 아무것도 걸리지 않으면 맨 끝의 MATCH가 받아냅니다. 국내 사이트는 직접 연결, 해외 사이트는 프록시로 보내는 분기는 모두 이 모드가 담당합니다.
• 전역 모드(global): 모든 트래픽이 현재 선택된 정책 그룹을 통과하며 규칙은 완전히 무시됩니다. 두 가지 상황에서만 사용합니다. 특정 노드가 살아 있는지 단독으로 테스트할 때, 그리고 어떤 사이트가 규칙에 의해 잘못 직접 연결로 분류되는지 판단할 때입니다.
• 직접 연결 모드(direct): 모든 트래픽이 프록시를 거치지 않습니다. 로컬 네트워크를 잠시 복구해야 하는데 클라이언트를 종료하고 싶지 않을 때 전환하면, 클라이언트를 껐다 켜는 것보다 빠릅니다.
• 스크립트 모드(script): JavaScript 한 조각으로 정책 선택을 동적으로 바꾸는 모드로, 일부 코어만 지원하므로 일반적인 사용에서는 건드릴 필요가 없습니다.

설정 위치는 클라이언트마다 다릅니다. Clash Verge Rev는 「프록시」 페이지 상단의 모드 드롭다운, Clash Plus는 메인 화면 상단의 모드 전환, Clash Meta for Android는 하단 내비게이션 「프록시」 페이지 오른쪽 위, ClashX Meta는 메뉴 막대의 「아웃바운드 모드」 하위 메뉴에 있습니다.

모드와 함께 정책 그룹도 이해해야 합니다. 프록시 페이지에서 정책 그룹 하나가 카드 하나로 표시되고, 카드 안에 선택 가능한 노드나 하위 그룹이 나열되며 카드 상단에 현재 선택된 항목이 보입니다. 규칙 모드에서 특정 규칙이 걸리면 실제 출구는 그 규칙이 가리키는 정책 그룹에서 현재 선택된 노드가 결정합니다. 그래서 「규칙 모드 + 자동 선택 그룹」이 평소 가장 편한 조합입니다. 규칙은 이 연결이 프록시를 거칠지 정하고, 자동 선택 그룹은 어느 노드로 나갈지 정합니다. 그룹에서 노드를 직접 클릭하면 자동 선택이 덮어써지므로, 다음에 그 노드가 죽으면 수동으로 되돌려야 합니다.

설정 파일에서 대응하는 필드는 이렇게 생겼습니다.

mode: rule
log-level: info
mixed-port: 7890
allow-lan: false
external-controller: 127.0.0.1:9090

클라이언트 화면에서 모드를 바꾸면 코어를 재시작하지 않아도 즉시 적용됩니다. 반대로 config.yaml 파일을 직접 편집한 뒤 클라이언트가 읽도록 하는 경우에는 설정을 다시 불러오거나 코어를 재시작해야 새 값이 반영됩니다. 모드를 바꾼 뒤에는 「연결」 페이지로 돌아가 몇 개의 기록을 확인해 새 모드에서 트래픽 흐름이 의도대로인지 본 다음 다음 단계로 넘어가세요.

모드는 분기 방식만 정할 뿐이므로 시스템 트래픽을 클라이언트로 넘겨야 합니다. Clash 클라이언트는 두 가지 방식을 제공하며 하나만 켜면 됩니다.

시스템 프록시: 운영체제에 HTTP/HTTPS 프록시 레코드를 기록해 클라이언트의 로컬 수신 포트를 가리킵니다. 켜는 속도가 빠르고 추가 권한이 필요 없으며 브라우저와 대부분의 데스크톱 프로그램을 커버합니다. 다만 시스템 프록시 설정을 읽지 않는 프로그램, 예를 들어 일부 명령줄 도구, 게임, 스토어 앱, 컨테이너는 커버하지 못합니다. 켜는 위치: Clash Verge Rev는 「설정」 페이지의 「시스템 프록시」 스위치, Clash Plus는 메인 화면 하단의 「시스템 프록시」 스위치, ClashX Meta는 메뉴 막대의 「시스템 프록시로 설정」입니다.

TUN 모드: 클라이언트가 가상 네트워크 어댑터를 만들어 IP 계층에서 컴퓨터 전체 트래픽을 가로채므로 모든 프로그램이 커버됩니다. 대신 관리자 권한이 필요하고(Windows에서는 처음 켤 때 시스템 서비스를 설치·시작해야 하고, macOS에서는 네트워크 확장을 승인해야 합니다) DNS도 올바르게 설정해야 합니다. 그렇지 않으면 이름 해석 오류가 나거나 일부 도메인이 열리지 않기 쉽습니다. 켜는 위치: Clash Verge Rev는 「설정」 페이지의 「TUN 모드」 스위치이며 처음 켤 때 서비스 설치 안내가 뜹니다. Clash Meta for Android는 「설정」 → 「네트워크」 → 「TUN」, ClashX Meta는 메뉴 막대의 「강화 모드」입니다.

두 방식을 동시에 켜지 마세요. 시스템 프록시 레코드와 가상 네트워크 어댑터가 함께 동작하면 트래픽 경로가 겹쳐 일부 요청은 정상이고 일부는 타임아웃되는 증상이 나타나며, 원인을 찾는 데 시간이 많이 걸립니다. 평소에는 시스템 프록시를 쓰고, 특정 프로그램이 적용되지 않을 때 TUN으로 전환하세요.

포트 설정: 클라이언트는 기본적으로 몇 개의 로컬 포트를 수신합니다. 7890(HTTP와 SOCKS5 혼합), 7891(SOCKS5), 7892(Redir), 9090(외부 제어 API)입니다. 포트를 다른 프로그램이 점유하고 있으면 클라이언트가 시작에 실패하거나 시스템 프록시 스위치가 켜지지 않습니다. 점유를 확인하는 명령은 다음과 같습니다.

# Windows
netstat -ano | findstr :7890

# macOS / Linux
lsof -i :7890

점유를 확인한 뒤에는 설정의 mixed-port를 7897 같은 빈 포트로 바꾸고 설정을 다시 불러온 다음, 시스템 프록시를 다시 한 번 켜세요. 시스템에 기록된 프록시 항목은 포트 변경을 자동으로 따라가지 않으므로 껐다 켜야 새 포트가 기록됩니다.

LAN 공유: allow-lan: true이면 같은 대역의 다른 기기가 이 컴퓨터를 프록시로 사용할 수 있으며, 방화벽 허용과 bind-address 설정이 함께 필요합니다. 한 대만 인터넷에 연결한다면 false로 두면 됩니다.

연결이 되었다고 스위치 색만 보지 말고, 아래 네 가지를 차례로 확인하세요.

1. 연결 페이지에 실시간 기록이 보입니다. 클라이언트의 「연결」 페이지를 열고 아무 웹페이지나 새로 고치면 목록에 해당 연결 항목이 나타나야 합니다. 각 기록에는 매칭된 규칙, 사용된 정책 그룹, 출구 노드, 업로드·다운로드 바이트 수가 표시됩니다. 목록이 계속 비어 있다면 트래픽이 클라이언트에 아예 도달하지 않은 것이므로, 노드가 아니라 시스템 프록시나 TUN이 실제로 동작하는지를 확인해야 합니다.
2. 출구 주소가 바뀝니다. 브라우저에서 아무 IP 조회 사이트에 접속했을 때 표시되는 지역이 통신사가 아니라 선택한 노드와 일치해야 합니다. 이 단계에서 트래픽이 실제로 원격지를 거쳤는지 확인합니다.
3. 분기가 의도대로 동작합니다. 「연결」 페이지로 돌아가 특정 도메인이 어느 규칙을 탔는지 봅니다. 국내 사이트는 직접 연결 계열 규칙에, 해외 사이트는 프록시 그룹에 걸려야 합니다. 국내 사이트가 대량으로 프록시를 통과한다면 규칙 세트가 로드되지 않았거나 GEOIP 데이터가 빠진 것이며, 보통 구독을 한 번 갱신하면 복구됩니다. 반대로 해외 사이트가 직접 연결된다면 규칙 순서에서 너무 넓은 규칙이 먼저 걸리지 않았는지 확인하세요.
4. 로그에 오류가 반복되지 않습니다. 로그 레벨을 info 또는 debug로 올리고 한동안 지켜봅니다. 정상 로그는 연결 생성과 종료 기록입니다. DNS 해석 실패, 연결 거부, TLS 핸드셰이크 타임아웃이 반복된다면 노드나 DNS 설정에 문제가 있다는 뜻이므로 노드 선택이나 DNS 설정으로 돌아가 점검해야 합니다.

명령줄 확인(선택):

curl -s -x http://127.0.0.1:7890 https://api.ipify.org

반환되는 주소는 노드의 출구 주소여야 합니다. curl이 바로 타임아웃되는데 브라우저는 정상이라면 그 터미널이 시스템 프록시를 상속하지 않은 것이며, 이는 정상적인 현상입니다. 명령줄 프로그램은 프록시 옵션을 직접 지정하거나 TUN 모드로 전환해야 합니다.

확인을 마치면 일상적인 사용에서는 클라이언트를 더 건드릴 일이 거의 없습니다. 남은 일은 구독을 최신 상태로 유지하고, 노드가 죽으면 정책 그룹에서 다른 노드로 바꾸고, 가끔 로그를 확인하는 정도입니다. 더 깊은 설정 항목, 즉 DNS와 Fake-IP의 동작 방식, 규칙 문법과 우선순위, rule-providers의 구조, TUN 스택 선택은 10분 안에 익히는 범위를 넘어서므로 「초보에서 심화까지」 장문에 정리해 두었습니다. 필요할 때 장별로 찾아보세요.