먼저 확인: 시간 초과가 속도 측정 중에 발생했나요, 실제 접속 중에 발생했나요?
클라이언트의 ‘프록시’ 페이지에서 현재 정책 그룹과 선택된 노드를 확인한 다음, ‘로그’ 페이지에서 실패한 요청을 살펴보세요. 클라이언트에 따라 두 페이지의 이름이 ‘프록시 그룹’, ‘실행 로그’ 등으로 표시될 수 있으니 실제 화면을 기준으로 확인합니다. 앱을 바로 재설치하거나 DNS, 규칙, 포트를 한꺼번에 바꾸지는 마세요.
노드 속도 측정은 보통 지정한 노드를 통해 테스트 주소에 요청을 보내고, 클라이언트 설정에 따라 지연 시간을 계산합니다. timeout이 표시되면 해당 테스트가 제한 시간 안에 끝나지 않았다는 뜻입니다. 테스트 주소를 사용할 수 없거나 DNS 조회 또는 노드 핸드셰이크에 실패해도 같은 결과가 나올 수 있습니다.
- 속도 측정은 시간 초과지만 웹페이지는 열림: 노드를 바로 삭제하지 말고 테스트 URL과 제한 시간을 먼저 확인하세요.
- 속도 측정에는 지연 시간이 표시되지만 특정 앱이 열리지 않음: 앱별 프록시 설정, 규칙 적용 결과, 앱 자체의 네트워크 설정을 먼저 확인하세요.
- 모든 노드에서 시간 초과가 발생하고 프록시 접속이 전부 실패함: 아래 순서에 따라 공통 원인을 확인하세요. 기기 네트워크를 먼저 살펴본 뒤 구독과 DNS를 점검합니다.
- 노드 하나만 실패함: 전체 설정을 바로 바꾸기보다 서버 주소가 다른 노드와 결과를 비교하세요.
1단계: 프록시를 중지하고 기기 네트워크와 VPN 인터페이스 확인
먼저 휴대전화가 프록시 없이 정상적으로 인터넷에 연결되는지 확인하세요
- 클라이언트 홈 화면에서 연결을 중지하고 Android 상태 표시줄에서 VPN 아이콘이 사라졌는지 확인하세요.
- 평소 프록시 없이 접속할 수 있는 웹사이트를 여세요. 공용 Wi-Fi에서 인증 페이지가 나타나면 로그인한 다음 클라이언트를 실행합니다.
- Wi-Fi를 끄고 모바일 데이터로 같은 노드를 테스트하세요. 그런 다음 Wi-Fi로 다시 전환하고 나머지 설정은 그대로 둡니다.
- 특정 Wi-Fi에서만 실패한다면 그 차이를 기록하세요. 모든 노드가 작동하지 않는다고 섣불리 판단하지 마세요.
Android의 VpnService는 앱이 기기 내 VPN 인터페이스를 만들 수 있도록 하는 시스템 기능입니다. 일반적인 개인 사용자 환경에서는 한 사용자에 활성 VPN 서비스가 하나만 실행되는 경우가 많습니다. 다른 VPN이나 방화벽, VPN 인터페이스를 사용하는 필터링 앱이 Clash의 인터페이스를 대체할 수 있습니다. 해당 서비스를 먼저 중지한 뒤 다시 연결하세요.
시스템 설정이 직접 연결을 차단하는지 확인
Android에서 ‘설정’ → ‘네트워크 및 인터넷’ → ‘VPN’으로 이동해 현재 클라이언트 옆의 설정 버튼을 누르고 ‘항상 사용 설정된 VPN’과 ‘VPN 연결 없이 연결 차단’을 확인하세요. 일부 기기에서는 ‘연결 및 공유’에 메뉴가 있습니다. 차단 옵션이 켜져 있다면 클라이언트를 중지한 뒤 인터넷이 안 되는 것은 Wi-Fi 문제가 아니라 시스템 설정에 따른 동작일 수 있습니다. 직접 연결과 비교하려면 해당 옵션을 잠시 끌 수 있습니다. 테스트 중 트래픽이 프록시를 거치지 않을 수 있으니 테스트가 끝나면 필요에 따라 다시 켜세요.
화면을 잠근 뒤에만 연결이 끊긴다면 잠금을 해제하고 서비스를 다시 시작하세요. 그런 다음 ‘설정’ → ‘앱’ → 현재 클라이언트 → ‘배터리’에서 백그라운드 제한을 확인합니다. 이 현상은 계속 발생하는 노드 핸드셰이크 시간 초과와 구분해 기록하세요.
2단계: 구독 업데이트 성공 여부와 설정 활성화 상태 확인
‘구성’ 페이지에서 현재 구독을 직접 업데이트하고 마지막 업데이트 시간과 오류 메시지를 확인하세요. 구독은 노드와 규칙을 가져오는 설정 출처입니다. 업데이트 실패와 프록시 연결 실패는 서로 다른 문제입니다. 이전 설정은 계속 사용할 수 있고, 업데이트에 성공해도 구독에 포함된 모든 서버에 연결할 수 있다는 뜻은 아닙니다.
- 현재 활성화된 설정이 방금 업데이트한 구성인지 확인하세요. 이름만 같은 예전 가져오기 파일일 수도 있습니다.
- 구독 서비스 관리 페이지에서 만료일, 남은 트래픽, 기기 수 또는 동시 연결 제한을 확인하세요.
- 업데이트 오류를 확인하세요. HTTP
401또는403은 보통 인증이나 접근 정책과 관련이 있고,404는 요청한 주소를 찾을 수 없다는 뜻입니다. 정확한 원인은 응답 내용과 함께 확인해야 합니다. - YAML 파싱 오류나 지원되지 않는 프록시 유형이 표시되면 노드 속도를 측정하기 전에 설정을 불러오지 못하는 문제부터 해결하세요.
YAML은 Clash 설정에 자주 쓰이는 텍스트 형식이며 들여쓰기가 구조 해석에 영향을 줍니다. 구독 URL을 노드 서버 주소로 사용하거나, 로그인 페이지 응답을 설정 파일로 저장하지 마세요. 화면에는 ‘다운로드 완료’라고 표시된 뒤 파싱 오류가 발생한다면 클라이언트에서 사용할 수 있는 설정을 가져오지 못했을 가능성이 큽니다.
3단계: 노드 도메인 DNS 조회와 대상 웹사이트 DNS 조회 구분
DNS는 도메인 이름을 IP 주소로 변환하는 조회 과정입니다. 프록시 접속 시 먼저 노드 서버 도메인을 조회한 다음, 기기나 원격 서버에서 대상 웹사이트를 조회할 수 있습니다. 어느 한쪽에서든 실패하면 화면에는 연결 시간 초과로 표시될 수 있습니다. 로그에 나온 도메인이 어느 쪽에 해당하는지 먼저 확인하세요.
| 확인된 현상 | 먼저 확인할 항목 | 다음 단계 |
|---|---|---|
| 노드 서버 도메인을 찾을 수 없다는 메시지가 표시됨 | 연결을 시작하기 전 DNS 경로 | 기기에서 해당 도메인을 조회할 수 있는지, 아직 연결되지 않은 노드에 조회 요청이 잘못 의존하는지 확인하세요. |
| 노드 핸드셰이크는 성공하지만 특정 웹사이트 접속 시 DNS 오류가 발생함 | 대상 도메인의 DNS와 규칙 | 다른 웹사이트와 비교하고 DNS 설정 및 연결 로그를 확인하세요. |
| Android 비공개 DNS를 켰을 때만 실패함 | 시스템 비공개 DNS에 연결할 수 있는지 확인 | 잠시 자동으로 설정한 뒤 같은 네트워크에서 다시 테스트하세요. |
| 네트워크를 바꿔도 이전 DNS 조회 결과가 계속 사용됨 | 앱과 커널 캐시 | 서비스를 중지했다가 다시 시작하고 같은 요청을 한 번 더 보내세요. |
Android에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘비공개 DNS’에서 시스템 설정을 확인할 수 있습니다. 비공개 DNS는 보통 암호화된 DNS over TLS를 사용하며, 설정 파일의 DNS over HTTPS와는 별개의 옵션입니다. 시스템 비공개 DNS를 잠시 ‘자동’으로 바꾸는 것은 비교 테스트일 뿐, 클라이언트 내부 DNS가 복구됐다는 뜻은 아닙니다.
mihomo는 Clash 설정 생태계와 호환되는 프록시 커널입니다. DNS 설정에서 proxy-server-nameserver는 노드 서버 도메인을 조회할 서버를 지정하고, default-nameserver는 DNS 서버 자체의 도메인 조회와 같은 초기 확인에 사용됩니다. 해당 필드가 작동하는지는 실제 커널 지원 여부에 따라 달라지므로 클라이언트 외부 앱의 이름만으로 판단할 수 없습니다. 연결할 수 없는 현재 프록시를 모든 DNS 요청의 경로로 강제하지 마세요. 서비스 시작에 서로 의존하는 순환 문제가 생길 수 있습니다.
인터넷에서 찾은 IP 주소로 노드 도메인을 함부로 바꾸지 마세요. TLS 서버 이름 확인, SNI, CDN 또는 로드 밸런서의 서버 선택에 원래 도메인이 필요할 수 있습니다. SNI는 핸드셰이크 중 접속하려는 서버 이름을 전달하는 값입니다. IP 주소로 바꾸면 TCP 연결은 성공해도 올바른 TLS 핸드셰이크가 완료되지 않을 수 있습니다.
4단계: 시스템 시간 보정 및 TLS 오류 확인
‘설정’ → ‘시스템’ → ‘날짜 및 시간’으로 이동해 ‘자동으로 시간 설정’과 ‘자동으로 시간대 설정’을 켜세요. 일부 기기에서는 ‘추가 설정’ → ‘날짜 및 시간’에 메뉴가 있습니다. 날짜와 연도가 현재와 일치하는지 확인한 다음 다시 연결하세요.
TLS는 연결을 암호화하고 서버 신원을 확인하는 프로토콜입니다. 인증서에는 유효 기간이 있으며, 일부 프록시 프로토콜은 시간 차이에도 민감합니다. 로그에 certificate has expired or is not yet valid가 표시되면 먼저 기기 시간을 확인하고 서버 인증서도 살펴보세요. 이 오류만으로 휴대전화 시간이 잘못됐다고 단정할 수는 없습니다.
x509: certificate signed by unknown authority: 인증서 체인이 불완전하거나 자체 서명된 인증서일 수 있으며, 중간 장비가 연결에 개입했을 수도 있습니다.- 인증서 이름이 일치하지 않음: 노드 도메인과 서비스에서 요구하는 서버 이름이 일치하는지 확인하세요.
- 시간이 정확한데도 인증서 오류가 발생하면 로그를 보관하고 서비스 제공자에게 인증서 배포와 접속 주소를 확인해 달라고 요청하세요.
오류를 없애려고 skip-cert-verify를 계속 켜 두지 마세요. 인증서 확인을 건너뛰면 서버 신원 검증이 약해지며, 포트 연결 문제나 잘못된 프로토콜 매개변수도 해결되지 않습니다.
5단계: 프로토콜, 서버 포트, 커널 지원 여부 확인
노드 상세 정보에서 프로토콜 유형, 서버 주소, 서버 포트를 확인한 뒤 클라이언트의 ‘정보’ 또는 커널 정보 페이지에서 실제 커널 버전을 기록하세요. Clash 클라이언트와 커널은 서로 다른 버전 개념입니다. 설정을 가져올 수 있어도 실행 중인 커널이 그 안의 모든 프로토콜과 필드를 지원한다는 뜻은 아닙니다.
로컬 수신 포트와 원격 서버 포트를 혼동하지 마세요
- 로컬 포트: 예를 들어 설정의
mixed-port: 7890은 기기 내 앱이 HTTP 또는 SOCKS 프록시에 연결할 때 사용합니다. 7890은 흔한 예시일 뿐이며 실제 설정을 확인하세요. - 서버 포트: 노드 상세 정보의
port는 원격 서버에 연결할 때 사용합니다. 443일 수도 있고 서비스 제공자가 지정한 다른 포트일 수도 있습니다. - 관리 포트:
external-controller는 제어 인터페이스이며, 브라우저로 웹사이트에 접속하는 프록시 주소가 아닙니다.
로컬 포트를 7890에서 7891로 바꿔도 원격 서버 포트가 차단된 문제는 해결되지 않습니다. 로그에 address already in use가 표시될 때는 로컬 포트가 사용 중인지, 서비스가 중복 실행됐는지 확인하세요.
전송 방식별로 비교 테스트
Hysteria2, TUIC 등은 UDP를 사용합니다. 일부 네트워크에서는 UDP가 제한되어 이런 노드만 실패하고 TCP 기반 노드는 작동할 수 있습니다. 서비스에서 제공하는 TCP 노드를 하나 선택해 같은 네트워크에서 비교하세요. 노드 설정에서 UDP 옵션만 끈다고 TCP로 전환되는 것은 아닙니다.
WebSocket 또는 gRPC를 사용하는 노드는 전송 경로, Host, 서비스 이름도 확인해야 합니다. HTTP 400, 404 응답이나 비정상적인 핸드셰이크가 나타나면 접속 매개변수가 맞지 않거나 서버 리버스 프록시 설정에 문제가 있을 수 있습니다. 필드를 하나씩 추측해 바꾸기보다 현재 커널과 호환되는 구독을 다시 받으세요.
6단계: 실제 트래픽이 올바른 정책 그룹으로 들어가는지 확인
‘연결’ 페이지를 연 다음 브라우저에서 대상 웹사이트에 접속하세요. 해당 요청이 표시되는지, 적용된 규칙과 정책 그룹, 최종 노드를 확인합니다. Rule 모드는 설정된 규칙에 따라 직접 연결 또는 프록시를 선택합니다. 선택한 노드는 해당 정책 그룹에만 적용되며 모든 직접 연결 규칙을 덮어쓰지는 않습니다.
- 요청이 표시되지 않으면 Android 앱별 프록시 설정에서 브라우저가 제외됐는지 확인하고 VPN 서비스가 실제로 실행 중인지 확인하세요.
- 요청에
DIRECT가 적용됐다면 프록시 그룹의 노드를 계속 바꾸지 말고 해당 규칙을 먼저 확인하세요. - 요청이 다른 정책 그룹으로 들어갔다면 해당 그룹에서 실제 선택 항목을 확인하세요. 그룹 안에서 여전히
DIRECT나 이전 노드가 선택되어 있을 수 있습니다. - 비교 테스트를 위해 잠시 Global 모드로 바꾸고 특정 노드를 선택할 수 있습니다. 테스트가 끝나면 Rule 모드로 복구해 임시 설정이 최종 설정으로 남지 않게 하세요.
Global 모드는 프록시 선택을 비교하는 데 쓰이며 기기의 모든 트래픽을 프록시로 보내는 기능은 아닙니다. 앱별 설정에서 제외된 앱이나 프록시 인터페이스에 들어오지 않은 트래픽은 모드를 바꿔도 표시되지 않습니다. 데스크톱의 TUN은 가상 네트워크 인터페이스로 트래픽을 처리하는 방식이고, Android 클라이언트는 보통 VpnService로 트래픽을 받습니다. 어느 방식도 작동하지 않는 서버나 잘못된 인증 정보를 해결해 주지는 않습니다.
데스크톱에서 추가 확인: 로컬 프록시 포트 지정
같은 구독을 컴퓨터에서도 사용한다면 컴퓨터 터미널에서 아래 명령을 실행할 수 있습니다. 이 예시에서는 컴퓨터 클라이언트의 HTTP 또는 mixed 포트가 실제로 7890이고 테스트 주소 https://example.com/도 접속 가능하다고 가정합니다. 이는 Android 시스템에 기본 제공되는 테스트 방법이 아닙니다.
curl --proxy http://127.0.0.1:7890 --connect-timeout 5 --max-time 15 -I https://example.com/127.0.0.1은 언제나 명령을 실행한 기기 자체를 가리킵니다. 컴퓨터에서 실행한 명령은 휴대전화 클라이언트에 자동으로 연결되지 않습니다. 다른 기기의 접속을 허용하려면 LAN 수신 설정과 접근 제어도 필요하므로 이번 문제 해결 과정에서 추가로 켜지 않는 것이 좋습니다. 명령으로 HTTP 응답을 받았더라도 해당 테스트 경로만 작동한다는 뜻이며 모든 앱이 프록시를 거친다는 증거는 아닙니다.
로그 오류 빠르게 확인하기: 연결 과정에서 가장 먼저 실패한 지점 찾기
‘로그’ 페이지에서 레벨을 잠시 info로 설정하세요. 정보가 부족하면 짧은 시간 동안 debug를 사용합니다. 요청을 보낸 정확한 시간을 기록하고 재현한 뒤 주변 로그를 보관하세요. 커널마다 메시지가 다를 수 있으므로 아래 표는 점검 방향을 찾는 참고 자료이며 전체 로그를 대신하지 않습니다.
| 로그 내용 | 일반적인 의미 | 다음 점검 항목 |
|---|---|---|
lookup … no such host | 도메인 조회 결과가 유효하지 않음 | 오류가 발생한 도메인이 노드 도메인인지 대상 도메인인지, DNS가 어떤 응답을 반환했는지 확인 |
dial tcp … i/o timeout | 지정된 주소와 TCP 연결이 제한 시간 안에 수립되지 않음 | 서버 주소와 포트, 현재 네트워크, 원격 서버 상태 확인 |
connection refused | 연결 시도가 거부 응답을 받음 | 대상 포트에서 서비스가 대기 중인지, 방화벽이 연결을 거부하는지 확인 |
TLS handshake timeout | TLS 핸드셰이크가 제한 시간 안에 완료되지 않음 | 네트워크 패킷 손실, 서버 부하, TLS 접속 지점, 서버 이름 매개변수 확인 |
authentication failed | 인증 실패 | 구독 상태, 비밀번호 또는 UUID, 프로토콜 요구 사항 확인 |
connection reset by peer | 상대편 또는 연결 경로의 장비가 연결을 재설정함 | 프로토콜 매개변수, 서버 로그, 네트워크를 바꿨을 때의 차이 확인 |
EOF | 읽기 작업 중 연결이 종료됨 | 앞선 핸드셰이크 및 인증 오류 확인. 이 메시지만으로 원인을 단정할 수 없음 |
예를 들어 노드 도메인 조회 실패가 먼저 나타난 다음 테스트 시간 초과가 발생했다면 DNS부터 해결하세요. 마지막 줄의 시간 초과만 유일한 원인으로 보지 마세요. 문제 해결이 끝나면 평소 사용하는 로그 레벨로 되돌려 불필요한 접속 기록이 쌓이지 않게 하세요.
모든 노드가 계속 시간 초과됨: 재현 가능한 정보 정리
직접 연결은 정상이고 구독이 유효하며 시스템 시간이 정확한데도 서로 다른 서버 두 곳 이상이 Wi-Fi와 모바일 데이터에서 모두 실패한다면, 관련 증거를 구독 서비스 제공자나 클라이언트 유지 관리 담당자에게 전달하세요. 여러 노드가 같은 접속 도메인을 공유한다면 서로 독립된 서버를 비교한 것으로 볼 수 없습니다.
- 환경: Android 버전, 클라이언트 이름과 버전, 커널 이름과 버전을 실제 화면에서 확인해 작성하세요.
- 시간: 실패한 날짜와 정확한 시각, 시간대를 적어 서버 기록과 대조할 수 있게 하세요.
- 범위: 모든 노드인지 특정 노드인지, 속도 측정만 실패하는지 실제 웹페이지 접속도 실패하는지 적으세요.
- 네트워크별 차이: Wi-Fi와 모바일 데이터에서 각각 3회 테스트한 결과와 공용 네트워크 인증 완료 여부를 적으세요.
- 로그: 첫 오류 전후의 필요한 행만 남기고 구독 토큰, 인증 정보, 개인 접속 도메인은 가리세요.
- 완료한 점검: 구독 업데이트 결과, 시스템 시간, DNS 비교 결과, 프로토콜 유형을 적어 같은 테스트를 반복하지 않도록 하세요.
문제 해결이 끝나면 임시로 바꾼 로그 레벨, 프록시 모드, 비공개 DNS, 시스템 VPN 차단 옵션을 원래대로 복구하세요. 설정을 계속 덧붙이는 것보다 문제를 재현할 수 있는 최소한의 절차를 정리하는 편이 원인을 찾기 쉽습니다.