1. Clash는 노드 서비스인가요? 구독 링크는 어디서 받나요
Clash, Clash Meta(현재는 보통 mihomo라는 이름을 사용) 및 다양한 그래픽 클라이언트는 설정을 읽고 규칙에 따라 연결을 전달합니다. 자체적으로 노드를 제공하지 않으며 설치 후 구독이 자동으로 생성되지도 않습니다. 구독 링크는 이용 중인 서비스 제공업체에서 발급받아야 하며, 보통 서비스 관리 페이지의 「구독」, 「원클릭 구독」 또는 「클라이언트 가져오기」 메뉴에서 확인할 수 있습니다.
하나의 구독은 보통 YAML 설정 또는 인코딩된 노드 목록을 반환합니다. 완전한 Clash 설정에는 서버 주소뿐 아니라 프록시 그룹, 규칙 세트, DNS 및 TUN 매개변수도 포함될 수 있습니다. 단일 노드 공유 링크만 있다면 수동으로 가져올 수도 있지만, 프록시 그룹과 분할 라우팅 규칙은 별도로 설정해야 합니다.
링크를 받은 뒤 먼저 확인할 세 가지
- 서비스 관리 페이지에서 제공하는 형식이 다른 클라이언트 전용 형식이 아닌 Clash 또는 Clash Meta 형식인지 확인하세요.
- 복사할 때
https://, 경로, 쿼리 매개변수와 토큰을 모두 포함하고 마지막 문자를 빠뜨리지 마세요. - 먼저 브라우저로 서비스 관리 페이지에 접속해 계정과 구독이 아직 유효한지 확인하세요. 로그인 페이지 주소를 구독 주소로 착각하지 않도록 주의해야 합니다.
2. 구독은 어떻게 가져오며, 가져온 뒤에도 업데이트해야 하는 이유는 무엇인가요
그래픽 클라이언트마다 메뉴 이름은 조금씩 다르지만 기본 순서는 같습니다. 일반적인 화면을 예로 들면 「구독」→「새 구독」으로 이동해 URL을 붙여 넣고 식별하기 쉬운 이름을 입력한 다음 「저장 후 업데이트」를 선택합니다. 다른 화면에서는 메뉴가 「설정」→「새로 만들기」→「URL」로 표시되기도 합니다. 가져오기가 완료되면 업데이트 시간, 설정 파일 이름과 프록시 수를 확인할 수 있어야 합니다.
“저장”은 주소만 기록하고, “업데이트”를 실행해야 원격 콘텐츠를 실제로 요청합니다. 처음 가져온 뒤 노드 목록이 비어 있다면 URL만 저장하고 업데이트를 실행하지 않은 경우가 가장 흔합니다. 자동 업데이트 간격은 서비스에서 허용하는 범위로 설정하세요. 예를 들어 1,440분마다 한 번이면 충분합니다. 5분마다 자주 업데이트해도 회선이 안정되는 것은 아니며, 오히려 서버의 요청 제한에 걸릴 수 있습니다.
업데이트에 실패했다면 다음 순서로 확인하세요
- 오류가
401또는403인지 확인하세요. 보통 토큰 만료, 계정 상태 이상 또는 요청 거부를 의미합니다. 404가 표시되면 구독 주소를 다시 복사하고 경로와 쿼리 매개변수가 모두 포함되었는지 중점적으로 확인하세요.- 연결 시간 초과가 발생하면 현재 프록시를 먼저 끄고 다시 업데이트하세요. 직접 연결로 서버에 접근할 수 없다면 사용 가능한 이전 설정을 활성화한 뒤 업데이트를 시도해 보세요.
- 업데이트가 완료되었는데 노드 수가 0이라면 다운로드한 내용이 YAML 또는 노드 목록이 아니라 웹 페이지 HTML인지 확인하세요.
- 설정 구문 분석 오류가 발생하면 로그의 줄 번호를 확인하세요. 서버가 호환되지 않는 필드를 반환했다면 Clash Meta 형식으로 전환하거나 mihomo 커널을 업데이트해야 합니다.
3. 구독 가져오기는 성공했는데 노드가 보이지 않는 이유
“구독이 존재하는 것”과 “현재 설정이 활성화된 것”을 먼저 구분해야 합니다. 많은 클라이언트가 여러 설정을 저장할 수 있지만 한 번에 하나만 불러옵니다. 「구독」 또는 「설정」 페이지에서 방금 업데이트한 설정을 선택한 뒤 「활성화」, 「현재 설정으로 지정」 또는 「전환」을 실행하세요. 그런 다음 「프록시」 페이지를 열고 정책 그룹에 노드가 표시되는지 확인합니다.
설정이 이미 활성화되었는데도 선택 항목이 없다면 규칙만 정의되어 있고 proxies 또는 proxy-providers가 정의되지 않았을 수 있습니다. 프록시 제공자가 첫 번째 가져오기를 아직 완료하지 못한 경우도 있습니다. provider 설정이라면 「프록시 제공자」 페이지에서 수동으로 업데이트하거나 로그에서 provider 이름을 검색하세요.
| 화면에 나타나는 현상 | 일반적인 원인 | 처리 방법 |
|---|---|---|
| 구독 카드는 있는데 프록시 페이지에는 이전 노드가 표시됨 | 새 설정이 현재 설정으로 지정되지 않음 | 새 설정을 선택하고 활성화 또는 전환 실행 |
| 프록시 그룹은 있지만 그룹 안이 비어 있음 | 프록시 제공자 가져오기에 실패함 | provider를 수동으로 업데이트하고 로그 확인 |
| 업데이트 시 구문 분석 실패가 표시됨 | YAML 들여쓰기, 필드 또는 형식이 호환되지 않음 | 구독 형식을 전환하거나 mihomo 커널 업데이트 |
| DIRECT와 REJECT만 표시됨 | 설정에 사용 가능한 프록시 정의가 포함되지 않음 | 서비스 관리 페이지에서 내보낸 설정 형식 확인 |
4. 노드가 모두 타임아웃되는 이유와 지연 시간 확인 방법
지연 시간 테스트는 노드 서버에 단순히 네트워크 탐색을 한 번 수행하는 방식이 아닙니다. Clash는 보통 해당 노드를 통해 테스트 URL에 요청을 보내고, 연결 수립부터 응답 수신까지 걸린 시간을 계산합니다. 따라서 “타임아웃”은 로컬 네트워크, 노드 진입점, 테스트 대상 사이트, DNS 조회 또는 TLS 핸드셰이크 중 어느 단계에서든 발생할 수 있습니다.
먼저 노드 3개만 따로 테스트해 한 번에 수십 개 회선에 요청을 보내는 일을 피하세요. 흔히 사용하는 테스트 URL은 https://www.gstatic.com/generate_204이며, 타임아웃 값은 우선 5,000밀리초로 설정할 수 있습니다. 현재 네트워크에서 이 주소에 접근할 수 없다면 서비스 제공업체가 안내한 HTTP 204 테스트 주소로 바꾸세요. 그렇지 않으면 모든 노드가 동시에 타임아웃으로 표시될 수 있습니다.
지연 시간 결과를 실용적으로 판단하는 방법
- 50~120밀리초: 일반적으로 웹 브라우징, 메신저와 일반적인 동영상 연결에 적합합니다.
- 120~250밀리초: 정상적으로 사용할 수 있지만 실시간 음성 통화나 원격 데스크톱에서는 응답이 느리게 느껴질 수 있습니다.
- 500밀리초 초과: 다른 회선으로 바꿔 다시 테스트하고 패킷 손실이나 잦은 연결 끊김이 함께 발생하는지 확인하세요.
- 항상 0밀리초로 표시됨: 실제 결과가 아닐 가능성이 큽니다. 테스트가 실행되지 않았거나 화면이 아직 갱신되지 않았을 수 있습니다.
- 모두 Timeout: 먼저 직접 연결 네트워크를 테스트한 뒤 시스템 시간, DNS, 커널 로그와 테스트 URL을 확인하세요.
5. 규칙, 전역, 직접 연결 모드 중 무엇을 선택해야 하나요
초보자의 일상적인 사용에는 규칙 모드를 우선 권장합니다. 규칙 모드는 위에서부터 도메인, IP, 프로세스 또는 규칙 세트를 차례로 확인한 뒤 연결을 지정된 정책 그룹으로 전달합니다. 한국 국내 서비스는 직접 연결하고 프록시가 필요한 대상은 노드로 보내며, 로컬 네트워크와 특수 주소도 설정에 따라 별도로 처리할 수 있습니다.
| 모드 | 연결 처리 방식 | 적합한 상황 |
|---|---|---|
| Rule | 규칙을 위에서부터 차례로 확인하고 일치하면 해당 정책 사용 | 일상적인 사용 및 장시간 실행 |
| Global | 프록시 가능한 대부분의 연결을 하나의 전역 정책 그룹으로 전달 | 접속 실패가 분할 라우팅 규칙 때문인지 임시로 확인할 때 |
| Direct | 프록시 노드를 거치지 않고 연결을 직접 전송 | 프록시 일시 중지, 로컬 네트워크 테스트 또는 구독 업데이트 |
규칙 모드에서 특정 웹사이트가 열리지 않으면 잠시 전역 모드로 전환해 테스트할 수 있습니다. 전역 모드에서 접속된다면 노드 자체는 정상일 가능성이 높으므로 해당 도메인에 어떤 규칙이 적용되었는지 확인하세요. 전역 모드에서도 실패한다면 노드, DNS와 대상 사이트 상태를 계속 점검해야 합니다. 테스트가 끝나면 규칙 모드로 돌아가 모든 연결이 하나의 노드에 장시간 몰리지 않도록 하세요.
로그에 표시되는 규칙 일치 정보는 매우 중요합니다. 로그 수준을 잠시 info로 설정하고 대상 사이트에 다시 접속한 뒤 도메인이 최종적으로 DIRECT, REJECT 또는 특정 프록시 그룹 중 어디로 들어갔는지 확인하세요. 점검이 끝난 뒤에는 debug를 계속 사용할 필요가 없습니다. 상세 로그는 파일 용량을 빠르게 증가시킵니다.
6. 시스템 프록시와 TUN 모드의 차이
시스템 프록시는 운영체제에 HTTP 및 SOCKS 프록시 주소를 기록하는 방식입니다. 시스템 프록시 설정을 따르는 브라우저와 앱은 연결을 Clash로 전달하며, 예를 들어 로컬에서 자주 사용하는 mixed 수신 주소는 127.0.0.1:7890입니다. 설정과 켜고 끄기가 간단하지만 일부 게임, 명령줄 도구, 스토어 앱과 자체 네트워크 스택을 사용하는 소프트웨어는 시스템 프록시를 무시할 수 있습니다.
TUN 모드는 가상 네트워크 인터페이스를 만들고 라우팅을 통해 더 많은 TCP, UDP 및 DNS 트래픽을 인계받습니다. 프록시를 수동으로 설정할 수 없는 앱에 적합하지만, 가상 네트워크 어댑터 생성과 라우팅 변경 권한을 운영체제에서 허용해야 합니다. Windows 클라이언트는 보통 먼저 서비스 모드를 설치해야 하며, macOS는 네트워크 확장 권한을 요청합니다. Linux는 이에 필요한 네트워크 관리 권한이 있어야 합니다.
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
strict-route: true
dns-hijack:
- any:53위 내용은 mihomo 설정에서 자주 사용하는 TUN 구조입니다. 실제로 사용할 수 있는 필드는 커널 버전과 클라이언트 관리 방식에 따라 달라집니다. 그래픽 클라이언트가 해당 매개변수를 이미 관리한다면 「설정」→「네트워크 설정」→「TUN 모드」에서 활성화하세요. 화면 설정과 구독 오버라이드에 서로 충돌하는 설정을 중복으로 관리하지 않는 것이 좋습니다.
초보자 선택 가이드
- 브라우저와 일반 데스크톱 앱만 사용한다면 먼저 시스템 프록시를 활성화하세요.
- 게임, 터미널 또는 특정 앱이 시스템 프록시를 읽지 않는다면 TUN을 활성화하세요.
- TUN을 활성화한 뒤 인터넷이 끊기면 TUN을 끄고 네트워크를 복구한 다음 서비스 모드, 라우팅과 DNS 로그를 확인하세요.
- 일부 클라이언트는 시스템 프록시와 TUN을 함께 관리할 수 있지만, 여러 도구를 추가로 설치해 라우팅을 중복으로 인계받게 하지 마세요.
7. 7890, 7891, 9090 포트는 각각 무엇을 하나요
포트는 로컬 프로그램이 Clash 커널에 연결하는 진입점입니다. 설정의 mixed-port: 7890은 HTTP와 SOCKS 프록시 연결을 모두 받을 수 있어 대부분의 데스크톱 클라이언트에 적합합니다. 오래된 설정에서는 HTTP를 7890, SOCKS를 7891에 배정하는 경우가 많습니다. external-controller: 127.0.0.1:9090은 그래픽 인터페이스가 커널을 제어할 때 사용하며, 일반 앱에 입력하는 프록시 포트가 아닙니다.
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090앱에서 프록시 주소를 입력해야 한다면 호스트 127.0.0.1과 mixed 포트 7890을 사용하면 됩니다. 브라우저 프록시 설정에 9090을 입력하지 마세요. 로컬 네트워크에 프록시를 공유하려면 allow-lan을 명시적으로 활성화하고 수신 주소를 설정한 뒤 시스템 방화벽에서 접근 출처를 제한해야 합니다. 로컬에서만 사용할 때는 꺼 두는 편이 관리하기 쉽습니다.
시작 로그에 address already in use가 나타나면 다른 프로세스가 해당 포트를 이미 사용 중이라는 뜻입니다. 「설정」→「매개변수 설정」에서 mixed 포트를 7890에서 7893 등으로 변경한 뒤 커널을 다시 시작하세요. 포트를 변경한 뒤 프록시 포트를 수동으로 설정한 브라우저, 터미널과 다른 앱도 함께 수정해야 합니다.
8. 브라우저는 접속되는데 다른 앱은 계속 직접 연결되거나 인터넷이 끊기는 이유
브라우저에서 접속된다는 것은 브라우저의 연결이 Clash로 들어갔다는 뜻일 뿐, 기기의 모든 트래픽이 인계되었다는 의미는 아닙니다. 먼저 브라우저에 별도의 프록시 확장 프로그램이 설치되어 있는지 확인하세요. 확장 프로그램이 127.0.0.1:7890을 직접 가리키고 있다면 시스템 프록시가 꺼져 있어도 브라우저는 Clash를 계속 사용할 수 있지만 다른 앱은 직접 연결할 수 있습니다.
앱 유형별 확인 방법
- 일반 데스크톱 앱: 「시스템 설정」→「네트워크 및 Internet」→「프록시」에서 주소와 포트가 클라이언트에 의해 올바르게 입력되었는지 확인하세요.
- 명령줄 도구: 해당 도구가
HTTP_PROXY,HTTPS_PROXY또는ALL_PROXY환경 변수를 읽는지 확인하세요. - 게임 및 UDP 앱: 시스템 HTTP 프록시만으로는 보통 적용되지 않으므로 UDP를 지원하는 노드를 사용하고 TUN을 활성화해야 합니다.
- Windows 스토어 앱: 일부 UWP 앱은 루프백 제한의 영향을 받으므로 대상 앱에 루프백 예외를 설정해야 합니다.
- 가상 머신 및 컨테이너: 내부의
127.0.0.1은 가상 환경 자체를 가리키므로 호스트 컴퓨터 주소를 직접 의미하지 않습니다.
점검할 때 클라이언트의 연결 목록을 연 다음 대상 앱에서 새 요청을 한 번 발생시키세요. 목록에 해당 도메인이나 프로세스가 전혀 없다면 트래픽이 아직 커널에 들어오지 않은 것입니다. 연결은 표시되지만 결과가 실패한다면 규칙 일치, 노드와 DNS를 확인하세요. 이렇게 하면 “트래픽 인계 문제”와 “프록시 문제” 사이를 반복해서 오가는 일을 줄일 수 있습니다.
9. 규칙이 적용되지 않는 이유와 사용자 지정 규칙을 넣을 위치
Clash 규칙은 설정에 적힌 순서대로 위에서 아래로 확인되며, 일반적으로 첫 번째 규칙과 일치하면 이후 규칙을 더 확인하지 않습니다. 따라서 더 구체적인 사용자 지정 규칙은 범위가 넓은 규칙보다 앞에 배치해야 하며, 최종 MATCH 규칙보다도 앞에 있어야 합니다. MATCH 뒤에 규칙을 추가하면 적용되지 않습니다.
rules:
- DOMAIN,api.example.com,Proxy
- DOMAIN-SUFFIX,example.com,Proxy
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- GEOIP,CN,DIRECT
- MATCH,ProxyDOMAIN은 완전한 도메인과 일치하고, DOMAIN-SUFFIX는 해당 접미사와 하위 도메인에 일치합니다. IP-CIDR은 네트워크 대역에 사용하며, 끝의 no-resolve는 일치 과정에서 IP를 얻기 위해 도메인을 능동적으로 조회하지 않는다는 뜻입니다. 규칙 마지막의 정책 이름은 proxy-groups의 그룹 이름과 대소문자 및 공백까지 완전히 같아야 합니다.
구독을 업데이트하면 원본 YAML이 자주 덮어써지므로 구독 파일을 직접 편집하는 것은 안전하지 않습니다. 오버라이드를 지원하는 클라이언트는 보통 「구독」→「오버라이드」 또는 「설정」→「설정 병합」 메뉴를 제공하며, 원격 규칙보다 앞에 사용자 지정 규칙을 삽입할 수 있습니다. 저장 후 설정을 다시 불러오고 연결 로그에서 실제로 적용된 규칙을 확인하세요.
10. 프록시 적용 여부를 확인하고 종료 전에 주의할 점
연결이 적용되었는지 확인할 때 클라이언트의 스위치만 보지 마세요. 먼저 직접 연결 모드에서 현재 외부 IP 정보를 기록한 뒤 규칙 모드로 전환하고 노드를 선택해 확인 페이지를 다시 여세요. 외부 IP와 지역이 예상대로 바뀌고 클라이언트 연결 목록에 해당 도메인이 나타난다면 요청이 프록시를 거친 것입니다.
이어서 DNS와 규칙을 확인하세요. 클라이언트 로그를 열고 직접 연결되어야 하는 한국 국내 사이트와 프록시를 사용해야 하는 대상을 각각 방문한 뒤, 두 요청이 각각 DIRECT와 지정된 프록시 그룹에 일치하는지 확인합니다. Fake-IP를 사용할 때 앱에 198.18.0.0/15 대역의 매핑 주소가 보이는 것은 일반적인 동작입니다. 실제 도메인은 여전히 커널이 매핑을 보관하며 규칙 매칭에 사용합니다.
첫 사용을 마친 뒤 확인할 체크리스트
- 현재 설정이 활성화되어 있고 구독 업데이트 시간과 노드 수가 정상입니다.
- 모드가 Rule로 설정되어 있으며 대상 정책 그룹에서 사용 가능한 노드가 선택되어 있습니다.
- 시스템 프록시 또는 TUN 중 하나 이상이 활성화되어 실제 앱 유형에 맞게 작동합니다.
- 연결 목록에서 대상 요청을 확인할 수 있고 규칙 일치 결과가 예상과 같습니다.
- 커널 로그에 포트 충돌, DNS 타임아웃 또는 provider 업데이트 실패가 지속적으로 나타나지 않습니다.
- 클라이언트를 종료할 때 시스템 프록시와 TUN 라우팅도 함께 복구해 시스템에 작동하지 않는 프록시 주소가 남지 않도록 하세요.
Clash를 종료한 뒤 웹 페이지가 모두 열리지 않으면 먼저 시스템 프록시 설정에서 프록시 스위치가 꺼졌는지 확인하세요. TUN 사용에 문제가 있다면 클라이언트를 종료한 후 네트워크에 다시 연결하고, 필요하면 시스템을 재시작해 라우팅을 복구하세요. 다시 시작하기 전에 7890 포트를 동시에 사용하거나 기본 라우팅을 인계받는 프록시 클라이언트를 여러 개 실행하지 마세요.
초보자 문제 해결은 일정한 순서로 진행하면 됩니다. 먼저 로컬 네트워크를 확인하고, 구독이 업데이트되었는지 점검한 다음 설정 활성화 여부, 노드 연결 상태, 모드와 정책 그룹을 확인하세요. 마지막으로 시스템 프록시 또는 TUN이 실제로 앱의 트래픽을 인계받는지 점검합니다. 한 번에 하나의 변수만 바꾸고 연결 목록과 로그에서 결과를 확인하면 클라이언트를 반복해서 재설치하는 것보다 대체로 빠르게 해결할 수 있습니다.