Clash에 “연결됨”이 표시되는 것은 보통 iOS 네트워크 확장, TUN 인터페이스 또는 로컬 프록시가 실행 중이라는 뜻일 뿐입니다. 이 상태만으로 구독이 유효하다고 볼 수 없고, 현재 정책 그룹이 사용 가능한 노드를 선택했다는 보장도 없습니다. 요청은 DNS 확인, 규칙 매칭, 정책 그룹, 원격 노드를 차례로 거치므로 어느 한 단계라도 실패하면 Safari가 계속 로딩되거나 앱에 네트워크 오류가 표시되거나 일부 웹사이트만 열리지 않을 수 있습니다.
문제 해결 중에는 여러 설정을 연달아 바꾸지 마세요. 먼저 현재 구성 이름과 정책 모드를 기록하고, 한 단계가 끝날 때마다 같은 웹페이지로 다시 테스트합니다. 먼저 Safari에서 http://captive.apple.com/hotspot-detect.html에 접속하는 것을 권장합니다. 정상 응답에는 보통 “Success”가 표시됩니다. 그런 다음 자주 사용하는 HTTPS 웹사이트에 접속하세요. HTTP와 HTTPS를 나누어 테스트하면 네트워크 진입 지점, DNS, TLS, 프록시 경로 문제를 1차로 구분할 수 있습니다.
1단계: Clash를 켰을 때만 문제가 발생하는지 확인
끄기와 켜기 상태를 비교 테스트하기
- 현재 Wi-Fi 또는 셀룰러 네트워크는 그대로 유지한 채 Clash의 프록시 스위치를 끕니다.
- Safari에서 앞서 접속에 실패했던 웹사이트 두 곳을 열고 한 번 새로 고칩니다.
- Clash를 다시 켜고 상태가 안정될 때까지 5초간 기다린 다음 같은 주소에 접속합니다.
- “끄면 정상이고 켜면 실패”인지, 아니면 두 상태 모두 실패하는지 기록합니다.
Clash를 꺼도 접속할 수 없다면 문제는 대개 로컬 네트워크, 통신사 연결 또는 웹사이트 자체에 있습니다. 먼저 비행기 모드, Wi-Fi 로그인 페이지, 셀룰러 데이터 권한을 확인하세요. 공용 Wi-Fi는 먼저 인증을 요구하는 경우가 많습니다. 이때는 Clash를 잠시 끄고 아무 HTTP 페이지에 접속해 로그인 페이지를 띄운 뒤 인증을 완료하고 프록시를 다시 켜세요.
끄면 정상이고 켜자마자 실패한다면 이 글의 순서대로 계속 확인하세요. 특정 앱에서만 문제가 발생한다면 iOS의 「설정」→「셀룰러」에서 해당 앱과 Clash 클라이언트에 셀룰러 데이터 권한이 있는지 확인합니다. 앱이 Wi-Fi에서만 작동하는지, 현재 Wi-Fi에 재인증이 필요한 포털이 활성화되어 있는지도 살펴보세요.
| 비교 결과 | 우선 확인 | 나중에 확인 |
|---|---|---|
| 끄고 켜도 모두 실패 | Wi-Fi 인증, 셀룰러 데이터, 시스템 네트워크 | 규칙 및 정책 그룹 |
| 끄면 정상, 켜면 실패 | 노드, 규칙, DNS, VPN 상태 | 라우터 초기화 |
| 웹페이지는 정상, 특정 앱만 실패 | 앱 권한, 규칙 매칭, UDP 지원 | 전체 구성 삭제 |
| 도메인 실패, 일부 IP는 연결 가능 | DNS 구성 및 변조 여부 | 노드를 계속 전환하기 |
2단계: 구독이 유효하고 전체 업데이트되었는지 확인
구독이 클라이언트에 표시된다고 해서 구독 주소를 여전히 읽을 수 있다는 뜻은 아닙니다. 서비스 만료, 구독 링크 만료, 서버의 로그인 페이지 반환, 업데이트 중 네트워크 끊김으로 클라이언트에 이전 구성이 남을 수 있습니다. 기존 노드가 모두 만료되면 화면에는 정책 그룹과 “연결됨”이 계속 표시되지만 실제 연결은 시간 초과될 수 있습니다.
업데이트 시간과 결과 확인하기
- 클라이언트의 구성 또는 구독 페이지에서 현재 활성화된 구성이 예상한 것인지, 예전에 가져온 로컬 사본이 아닌지 확인합니다.
- 마지막 업데이트 시간을 확인합니다. 구독 제공자가 노드를 교체했는데 로컬 업데이트 시간이 며칠 전으로 남아 있다면 수동으로 한 번 업데이트하세요.
- 업데이트 후에도 정책 그룹에 노드가 포함되어 있는지 확인합니다. 그룹 이름만 있고 선택 가능한 노드가 없다면 대개 구독 내용이 비어 있거나 파싱에 실패한 것입니다.
- HTTP
401또는403이 표시되면 구독 권한과 주소를 확인하세요.404라면 보통 구독 링크를 다시 발급받아야 하며,5xx라면 서버가 복구된 뒤 다시 시도합니다.
구독을 업데이트하기 전에 기존 구성을 먼저 삭제하지 마세요. 기존 구성은 보존하고 새 구성 슬롯을 만들어 업데이트된 주소를 가져온 뒤 정상적으로 로드되는지 확인하고 전환하는 편이 안전합니다. 새 구독에 호환되지 않는 필드가 포함되어도 원래 구성으로 빠르게 돌아가 차이를 확인할 수 있습니다.
3단계: 정책 그룹이 실제로 사용 가능한 노드를 선택했는지 확인
Clash 구성에서 자주 사용하는 정책 그룹 유형에는 select、url-test、fallback 및 load-balance가 있습니다. 이 중 select는 수동 선택이 필요하며, 자동 테스트 그룹은 테스트 주소, 테스트 간격, 노드 연결 가능 여부에 따라 작동합니다. 그룹 안에 노드 이름이 표시된다는 것은 구성이 로드되었다는 뜻일 뿐, 노드 핸드셰이크가 성공했다는 의미는 아닙니다.
자동 테스트의 영향을 배제하려면 먼저 수동 선택하기
- 정책 그룹 페이지를 열고 규칙에서 최종적으로 참조하는 기본 프록시 그룹(예: “노드 선택” 또는 “PROXY”)을 찾습니다.
- 하위 지역 그룹만 전환하지 마세요. 최상위 기본 그룹이
DIRECT、REJECT또는 만료된 자동 그룹으로 설정되어 있지 않은지 확인합니다. - 명확한 단일 노드를 수동으로 선택한 뒤 서로 다른 지역의 노드 두세 개로 연속 테스트합니다.
- 전환할 때마다 3~5초 기다린 후 웹페이지를 다시 열어 이전 연결이 재사용되어 잘못 판단하지 않도록 합니다.
지연 시간 테스트는 해당 시점에 테스트 URL에 연결할 수 있었다는 사실만 보여 줍니다. 80ms로 표시된 노드도 대상 웹사이트에 접속하지 못하거나 UDP가 지원되지 않거나 TLS 핸드셰이크에 실패하거나 출구가 제한될 수 있습니다. 반대로 테스트 시간 초과도 테스트 주소가 차단된 결과일 수 있어 노드 자체는 다른 사이트에 접속될 수 있습니다. 따라서 실제 웹페이지 결과와 연결 로그를 함께 확인하고 지연 시간 숫자만 보지 마세요.
자주 발생하는 연결 오류 식별하기
| 로그 또는 증상 | 일반적인 원인 | 해결 방법 |
|---|---|---|
i/o timeout |
노드 주소에 연결할 수 없거나 포트가 차단되었거나 경로가 시간 초과됨 | 노드를 바꾸고 Wi-Fi와 셀룰러 네트워크에서 비교 테스트 |
connection refused |
원격 포트가 수신 대기 중이 아니거나 노드가 이미 종료됨 | 구독을 업데이트하고 해당 노드 비활성화 |
TLS handshake timeout |
경로 패킷 손실, SNI 또는 서버 측 TLS 오류 | 노드를 바꾸고 시스템 시간 확인 |
| 속도 측정은 정상인데 웹페이지가 시간 초과됨 | 규칙이 잘못된 정책 그룹으로 연결되었거나 대상 사이트가 출구를 제한함 | 해당 요청의 규칙 매칭 기록 확인 |
4단계: 모드와 규칙 매칭 확인
규칙 모드에서는 요청이 위에서 아래 순서로 매칭되며, 한 규칙에 매칭되면 뒤의 규칙은 확인하지 않습니다. 범위가 지나치게 넓은 DOMAIN-SUFFIX、IP-CIDR 또는 GEOIP 규칙 하나 때문에 대상 요청이 잘못된 정책 그룹으로 들어갈 수 있습니다. 마지막 MATCH 또는 FINAL도 실제로 존재하고 사용할 수 있는 그룹을 가리켜야 합니다.
잠시 글로벌 모드로 비교하기
모드를 “규칙”에서 “글로벌”로 잠시 전환하고, 글로벌 정책에서 사용 가능하다고 확인한 노드를 선택합니다. 웹페이지가 복구되면 노드와 기본 프록시 경로는 대체로 정상이며 문제는 규칙 매칭 또는 정책 그룹 참조에 집중됩니다. 글로벌 모드에서도 실패한다면 노드, DNS 또는 시스템 VPN 단계로 돌아가 계속 확인하세요.
글로벌 모드는 원인 파악용이지 최종 해결책이 아닙니다. 원인을 확인한 뒤 규칙 모드로 돌아가 연결 기록에서 실패한 도메인에 적용된 정책과 규칙을 찾으세요. 예를 들어 로그에 요청이 DIRECT에 매칭되었지만 현재 네트워크에서 해당 대상에 직접 연결할 수 없다면 규칙 순서를 조정하거나 규칙 세트를 바꿔야 합니다. 빈 정책 그룹에 매칭되었다면 구성의 그룹 이름 참조를 수정하세요.
rules:
- DOMAIN-SUFFIX,example.com,PROXY
- GEOIP,CN,DIRECT
- MATCH,PROXY위 규칙은 먼저 example.com과 그 하위 도메인을 PROXY로 보내고, GEOIP CN에 해당하는 대상은 직접 연결하며, 나머지 요청은 PROXY로 보냅니다. 대상 도메인 규칙보다 앞에 범위가 넓은 직접 연결 규칙을 배치하면 뒤의 규칙은 매칭될 기회를 얻지 못할 수 있습니다.
5단계: DNS 오류와 프록시 오류 구분하기
DNS 오류의 대표적인 증상은 도메인이 열리지 않고 앱에 서버를 찾을 수 없다는 메시지가 표시되지만, 이미 연결된 서비스나 고정 주소를 사용하는 일부 서비스는 계속 작동하는 것입니다. Clash Meta（mihomo）에서 흔히 사용하는 강화 모드는 fake-ip와 redir-host입니다. iOS TUN 또는 네트워크 확장 환경에서는 DNS 요청이 시스템 암호화 DNS, 다른 VPN 구성, 로컬 네트워크의 DNS 변조 영향을 받을 수도 있습니다.
먼저 로그에 이름 확인 오류가 있는지 확인하기
no such host는 일반적으로 도메인 이름 확인 실패를 의미합니다.context deadline exceeded는 상위 DNS 서버 시간 초과일 수도 있고, 상위 요청이 사용할 수 없는 프록시 그룹을 거쳐야 하는 상황일 수도 있습니다.- 로컬 네트워크 도메인만 실패한다면 라우터 DNS(예:
192.168.1.1)로 해결해야 하는지 확인하세요. - 네트워크를 바꾼 뒤 복구된다면 대개 기존 Wi-Fi의 DNS, 인증 상태 또는 UDP 전송에 제한이 있다는 뜻입니다.
클라이언트에 「설정」→「매개변수 설정」→「DNS」와 같은 메뉴가 있다면 현재 값을 먼저 기록한 뒤 DNS 활성화 여부, 강화 모드가 구성과 일치하는지, 상위 주소 형식이 완전한지 확인합니다. 클라이언트마다 메뉴 이름은 다를 수 있습니다. 구독이 구성을 관리하는 경우에는 독립 사본을 우선 수정해 다음 구독 업데이트에서 로컬 변경 사항이 덮어써지지 않도록 하세요.
dns:
enable: true
listen: 0.0.0.0:1053
enhanced-mode: fake-ip
nameserver:
- 1.1.1.1
- 8.8.8.8
fallback:
- tls://1.1.1.1:8531053은 예시 수신 대기 포트이며 다른 로컬 DNS 서비스와 충돌해서는 안 됩니다. 기존 DNS는 보통 UDP 또는 TCP 53번 포트를 사용하고, DNS over TLS는 보통 853번 포트를 사용합니다. 구독 구조를 정확히 모르는 상태에서 nameserver、fallback、proxy-server-nameserver 및 fake IP 범위를 동시에 변경하지 마세요. 먼저 연결 가능한 상위 서버 하나만 바꾼 뒤 다시 테스트해야 어떤 변경이 적용되었는지 알 수 있습니다.
iPhone에 별도의 암호화 DNS 프로파일이 설치되어 있다면 「설정」→「일반」→「VPN 및 기기 관리」에서 확인할 수 있습니다. 문제를 확인하는 동안에는 다른 DNS 또는 VPN 구성을 잠시 비활성화하고 현재 Clash 네트워크 확장만 남겨 두세요. 테스트가 끝나면 원래 설정을 복원합니다.
6단계: iOS VPN 및 TUN 상태 확인
iOS에서는 일반적으로 한 번에 하나의 주요 VPN 터널만 트래픽을 제어할 수 있습니다. 기업용 VPN, 다른 프록시 클라이언트, 콘텐츠 필터 또는 보안 소프트웨어가 Clash 네트워크 확장과 충돌할 수 있습니다. 상태 표시줄에 VPN 표시가 나타나도 어떤 VPN 구성이 활성화되어 있는지만 알 수 있을 뿐, 실제로 적용 중인 구성이 무엇인지는 알 수 없습니다.
시스템 설정에서 현재 구성 확인하기
- 「설정」→「일반」→「VPN 및 기기 관리」→「VPN」을 엽니다.
- 현재 연결 항목이 사용 중인 Clash 클라이언트에 속하는지 확인합니다.
- 다른 VPN 연결을 끊고 다른 프록시 클라이언트의 주문형 연결을 끕니다.
- Clash로 돌아가 프록시를 먼저 끄고 5초간 기다린 다음 다시 켭니다.
- 계속 연결 상태에서 멈춘다면 iPhone을 재시동한 뒤 Clash만 실행하고 다른 네트워크 도구는 동시에 열지 마세요.
TUN 모드를 사용할 때 클라이언트는 가상 네트워크 인터페이스를 만들고 해당 트래픽을 제어해야 합니다. 구성의 라우팅 제외 항목이 너무 넓으면 요청이 TUN을 우회할 수 있고, 너무 좁으면 로컬 네트워크 기기 접근에 영향을 줄 수 있습니다. 프린터, NAS 또는 라우터 관리 페이지만 열리지 않는다면 10.0.0.0/8、172.16.0.0/12 및 192.168.0.0/16과 같은 로컬 네트워크 주소가 직접 연결로 남아 있는지 확인하세요.
셀룰러 네트워크에서만 문제가 발생한다면 「설정」→「셀룰러」에서 Clash 클라이언트가 셀룰러 데이터를 사용할 수 있는지 확인합니다. 듀얼 SIM 기기에서는 현재 데이터 회선이 정상적으로 등록되어 있는지도 확인하세요. SIM 데이터 회선을 바꾼 뒤에는 VPN 연결을 끊었다가 다시 만들어 네트워크 확장이 새 기본 경로를 가져오도록 합니다.
7단계: 로그로 문제가 발생한 단계를 특정하기
앞의 비교 테스트를 마치면 로그를 통해 문제를 명확한 단계로 좁힐 수 있습니다. 클라이언트의 연결 또는 로그 페이지를 열고 이전 기록을 지운 다음 테스트 도메인 하나만 방문하세요. 시간, 도메인, 매칭된 규칙, 정책 그룹, 노드 이름, 최종 오류를 기록합니다. 여러 앱을 동시에 열면 백그라운드 요청이 대상 기록을 빠르게 묻어 버립니다.
요청 단계별로 로그 읽기
- 요청 기록이 전혀 없음: 트래픽이 Clash에 들어오지 않았을 수 있습니다. VPN 구성, TUN 상태, 앱 네트워크 권한을 확인하세요.
- 도메인은 표시되지만 확인할 수 없음: DNS 상위 서버, 암호화 DNS 구성, DNS 관련 로그를 확인하세요.
- 규칙 매칭이 이미 표시됨: 매칭된 정책 그룹이 예상과 일치하는지 확인하세요.
- 노드를 선택했지만 연결 시간 초과: 노드와 네트워크를 바꿔 노드 자체의 문제인지 현재 경로가 차단된 것인지 판단하세요.
- TCP 연결 후 TLS 오류 발생: 시스템 시간, 대상 도메인, 노드 경로, 인증서 경고를 확인하고 출처를 알 수 없는 인증서를 바로 허용하지 마세요.
클라이언트가 로그 수준을 지원한다면 문제를 확인하는 동안 info에서 debug로 잠시 올린 뒤 한 번 재현하고 즉시 되돌립니다. debug를 계속 사용하면 기록이 지나치게 많아져 중요한 오류를 찾기 어려워집니다. 문제를 제출할 때는 구독 주소, 인증 정보, 노드 비밀번호, 개인 도메인을 가리고 오류 유형과 필요한 맥락만 남기세요.
최종 체크리스트: 결과에 따라 다음 단계 결정
- Clash를 꺼도 인터넷이 되지 않음: 먼저 Wi-Fi 로그인, 셀룰러 권한 또는 시스템 네트워크를 처리하세요.
- 구독 업데이트 오류: 구독 권한, 서버 응답 내용, 구성 형식을 확인하세요.
- 수동 노드는 사용 가능하지만 자동 그룹은 사용 불가: 테스트 URL, 그룹 유형, 테스트 간격을 확인하세요.
- 글로벌 모드는 사용 가능하지만 규칙 모드는 사용 불가: 요청 매칭을 확인하고 규칙 순서를 조정하세요.
- 도메인 접속 실패와 로그의 DNS 시간 초과: DNS 상위 서버와 시스템 암호화 DNS를 확인하세요.
- 로그에 요청이 없음: 현재 iOS VPN 구성과 TUN이 실제로 트래픽을 제어하는지 확인하세요.
- Wi-Fi는 실패하지만 셀룰러는 정상: 공용 네트워크 인증, 라우터 DNS, 포트 제한을 확인하세요.
- 모든 노드에서 연결 시간 초과: 구독을 업데이트하고 노드 서비스 제공자에게 경로 상태를 확인하세요.
가장 효율적인 문제 해결 순서는 끄기·켜기 비교, 구독과 노드 확인, 규칙과 DNS 점검, 마지막으로 시스템 VPN 확인입니다. 각 단계에서는 변수 하나만 바꾸고 같은 웹사이트로 다시 테스트하세요. 그러면 노드 오류를 DNS 문제로 잘못 판단하는 일을 피하고, 설정을 한꺼번에 초기화해 재현 가능한 단서를 잃는 것도 막을 수 있습니다.