1. 먼저 ‘커널 실행’과 ‘웹페이지 접속’을 구분하세요

클라이언트가 정상 작동 중이라는 표시는 보통 커널이 실행 중이거나 시스템 프록시가 켜져 있다는 뜻입니다. 노드 지연 시간 테스트에 성공했더라도 해당 시점의 테스트 요청이 완료됐다는 것만 확인할 수 있습니다. 브라우저에서 다른 도메인에 접속할 때는 규칙, 정책 그룹, DNS 경로가 다를 수 있습니다. 따라서 ‘연결됨’ 표시만 보고 사이트 문제라고 단정하지 말고, 포트와 DNS, 규칙을 한꺼번에 바꾸지도 마세요.

문제 해결을 시작하기 전에 클라이언트 이름, 커널 종류, 현재 설정 이름, 작동 모드, 로컬 수신 포트를 기록해 두세요. Clash와 Clash Meta(현재 mihomo)는 지원하는 설정 기능이 완전히 같지 않고, 그래픽 인터페이스의 메뉴도 클라이언트마다 다릅니다. 아래에서는 ‘시스템 프록시’, ‘연결’, ‘로그’ 등의 기능 이름으로 안내하며, 운영체제 메뉴는 구체적인 경로를 표시합니다.

  1. 현재 사용 중인 설정이 실제로 선택되어 있는지 확인하세요. 구독을 다운로드한 것만으로는 충분하지 않습니다.
  2. 웹페이지에 표시된 오류를 기록하세요. 예: ERR_PROXY_CONNECTION_FAILED, ERR_NAME_NOT_RESOLVED, 연결 시간 초과.
  3. 접속에 실패하는 URL 하나를 테스트 대상으로 정하고, 설정을 변경할 때마다 다시 요청해 결과를 기록하세요.
  4. 여러 프로그램이 동시에 프록시 설정을 바꾸지 않도록 다른 프록시 클라이언트, 브라우저 프록시 확장 프로그램, 네트워크 가속 도구를 잠시 종료하세요.

2. 프록시를 끄고 로컬 네트워크 상태 확인하기

먼저 클라이언트의 시스템 프록시와 TUN을 끈 다음, 시스템에 수동 프록시 설정이 남아 있는지 확인하세요. Windows 11에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’를 여세요. macOS에서는 ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 연결 → ‘세부사항’ → ‘프록시’로 이동하세요. PAC 자동 구성 스크립트를 사용 중이라면 스크립트 주소도 기록해 두어 PAC 설정과 수동 프록시를 혼동하지 않도록 하세요.

그다음 현재 네트워크에서 직접 접속할 수 있어야 하는 사이트를 열고, Wi-Fi 로그인 인증이 필요한지도 확인하세요. 호텔, 학교, 공용 네트워크에서 인증을 완료하지 않았다면 클라이언트를 실행해도 로컬 네트워크 접속 제한을 우회할 수 없습니다. 터미널에서 다음 명령을 실행해 HTTPS 직접 연결이 되는지 확인할 수 있습니다.

curl -I --noproxy "*" --connect-timeout 10 https://example.com/

Windows에서는 구버전 Windows PowerShell이 curl을 다른 명령으로 해석하지 않도록 curl.exe를 사용하는 것이 좋습니다. 이 명령은 지정한 사이트만 테스트하므로 실패하더라도 네트워크 전체가 끊겼다는 뜻은 아닙니다. 로컬에서 접속 가능한 다른 사이트나 모바일 핫스팟으로도 확인하세요. 모든 프록시를 끈 뒤에도 라우터 관리 페이지와 자주 이용하는 직접 연결 사이트에 접속할 수 없다면 네트워크 연결, 인증 또는 시스템 네트워크 설정부터 점검하세요.

3. 시스템 프록시 주소와 로컬 수신 포트 확인하기

포트를 확인한 다음 시스템 프록시를 켜세요

클라이언트 설정에서 HTTP 포트 또는 혼합 포트를 확인하고 운영체제의 프록시 주소와 하나씩 대조하세요. 예를 들어 설정이 실제로 mixed-port: 7890에서 수신 중이라면 같은 컴퓨터의 수동 프록시 주소로 127.0.0.1:7890을 사용할 수 있습니다. 여기서 7890은 예시이며 모든 클라이언트의 기본값은 아닙니다. 화면에 7897로 표시된다면 명령과 시스템 설정 모두 실제 포트 번호로 맞추세요.

HTTP 프록시 포트와 SOCKS 전용 포트는 임의로 바꿔 사용할 수 없습니다. 시스템 설정이 이미 닫힌 포트를 가리키면 브라우저에 프록시 연결 실패가 바로 표시될 수 있습니다. 시스템 프록시 설정을 거치지 않고 HTTP 프록시를 직접 지정해 테스트할 수 있습니다.

curl -I --proxy http://127.0.0.1:7890 --connect-timeout 10 https://example.com/
  • 프록시를 직접 지정하면 성공하지만 브라우저에서는 실패: 다른 프로그램이 시스템 프록시를 바꿨는지, 브라우저 확장 프로그램이 설정을 덮어쓰는지, 브라우저가 별도의 프록시 설정을 사용하는지 확인하세요.
  • 127.0.0.1에 즉시 연결할 수 없다는 메시지가 표시됨: 커널이 실행 중인지, 포트가 수신 대기 중인지 먼저 확인하세요. 이 단계에서는 원격 노드를 바꿀 필요가 없습니다.
  • 200 Connection established가 표시된 후에도 실패: HTTP 프록시가 터널 요청을 수락했다는 뜻일 뿐, 이후 TLS 핸드셰이크나 웹페이지 응답까지 성공했다는 뜻은 아닙니다.
  • 407 응답이 반환됨: 로컬 프록시에 인증이 설정되어 있는지 확인하세요. 인증 실패를 노드 시간 초과로 오해하지 마세요.

포트를 사용하는 프로세스가 현재 클라이언트인지 확인하세요

Windows 터미널에서 다음 명령을 실행해 수신 대기 상태와 프로세스 ID를 확인하세요. macOS에서는 두 번째 명령으로 수신 대기 프로세스를 확인할 수 있습니다.

netstat -ano | findstr ":7890"
lsof -nP -iTCP:7890 -sTCP:LISTEN

Windows 결과에서는 로컬 주소와 LISTENING 상태를 확인한 다음, ‘작업 관리자’ → ‘세부 정보’에서 PID로 프로세스를 대조하세요. 출력에 포트 번호가 보인다는 이유만으로 정상적으로 수신 중이라고 판단하지 마세요. 이전 클라이언트가 포트를 사용 중이라면 해당 프로그램을 정상 종료하거나 현재 클라이언트의 포트를 비어 있는 포트로 바꾸고 시스템 프록시도 같은 값으로 변경하세요. 이 컴퓨터에서만 사용할 경우 보통 ‘LAN 연결 허용’을 켤 필요가 없습니다.

4. 연결 기록으로 규칙과 정책 그룹 확인하기

규칙 모드를 유지한 채 클라이언트의 ‘연결’ 또는 ‘로그’ 화면을 열고, 접속에 실패한 웹페이지를 새로고침하세요. 대상 도메인, 일치한 규칙, 정책 그룹, 최종 출구를 기록합니다. 기존 장기 연결은 노드를 바꾼 뒤에도 이전 출구를 계속 사용할 수 있으므로, 해당 연결을 닫거나 브라우저를 다시 시작한 후 테스트하세요. 기록이 전혀 없다면 로그에서 대상 요청이 필터링되지 않았는지 먼저 확인하세요. 그래도 기록이 없으면 프록시 진입 경로를 다시 점검하세요.

관찰된 결과우선 확인할 항목다음 단계
대상 연결에 REJECT 규칙이 적용됨도메인 규칙, 규칙 세트, 광고 차단 규칙문제가 된 항목을 찾아 로그인·인증·정적 리소스 도메인이 잘못 차단됐는지 확인하세요
대상 연결이 DIRECT로 처리됨현재 네트워크에서 해당 사이트에 직접 연결할 수 있는지일치한 도메인 규칙과 마지막 기본 규칙 확인
프록시 그룹을 거치지만 연결 시간 초과그룹에서 실제로 선택된 노드와 중첩된 정책 그룹사용 가능한 다른 출구로 바꾸고 같은 URL을 다시 테스트하세요
일부 리소스만 로드되지 않음이미지, 스크립트, API별 출구페이지의 기본 도메인뿐 아니라 실패한 도메인별로 확인하세요

Clash 규칙은 위에서부터 순서대로 검사하며 처음 일치하는 규칙이 적용됩니다. 범위가 지나치게 넓은 DOMAIN-SUFFIX 규칙이 앞에 있으면 뒤에 있는 더 구체적인 규칙이 적용되지 않을 수 있습니다. 규칙 문제로 의심된다면 잠시 전역 모드로 전환하고 사용 가능한 노드를 직접 선택해 비교하세요. 같은 URL이 전역 모드에서는 열리고 규칙 모드에서는 열리지 않는다면 전역 모드를 계속 사용해 설정 문제를 덮어두기보다 출구와 일치 기록을 중점적으로 비교하세요.

5. 시스템 DNS와 커널 DNS 문제 구분하기

브라우저에 도메인 이름을 확인할 수 없다는 오류가 표시되더라도 시스템 DNS만의 문제라고 단정할 수는 없습니다. 시스템 리졸버, 브라우저의 보안 DNS, 커널 DNS, 원격 노드가 함께 도메인 조회에 관여할 수 있으며 실제 경로는 프록시 방식과 설정에 따라 달라집니다. 먼저 다음 명령을 실행해 시스템 리졸버가 대상 도메인에 응답하는지 확인하세요.

nslookup example.com

nslookup이 성공해도 이번 시스템 측 조회에 응답이 왔다는 뜻일 뿐, 커널에서 사용하는 상위 DNS 서버가 정상이라는 뜻은 아닙니다. 반대로 시스템 조회가 실패해도 프록시 측에서 도메인을 조회하는 요청까지 반드시 실패하는 것은 아닙니다. HTTP 프록시로 HTTPS 사이트에 접속하면 클라이언트가 대상 도메인을 전달하는 경우가 많습니다. SOCKS 테스트에서는 socks5://와 socks5h://가 도메인을 조회하는 위치가 다르므로 결과를 비교할 때 이 차이를 고려하세요.

실제 DNS 조회 경로에 따라 단계별로 확인하기

  1. 로그에서 DNS, resolve, timeout을 검색하고 오류가 난 도메인과 상위 DNS 서버 주소를 확인하세요. 마지막 시간 초과 기록만 확인하지 마세요.
  2. DoH 또는 DoT를 사용한다면 상위 DNS 서버 주소에 접속할 수 있는지 확인하세요. 상위 서버 주소에 도메인 이름을 사용한다면 부트스트랩 조회가 순환 의존하지 않는지도 점검해야 합니다.
  3. 브라우저의 ‘보안 DNS’를 잠시 끄고 비교 테스트한 뒤 원래 설정으로 되돌리세요. 브라우저 자체의 암호화 DNS 연결은 시스템 리졸버와 다른 경로를 사용할 수 있습니다.
  4. fake-ip를 사용할 때 198.18.0.0/15 범위의 매핑 주소가 보인다고 해서 곧바로 DNS 오류인 것은 아닙니다. 이후 연결이 커널에서 가로채지고 도메인이 올바르게 복원되는지 확인하세요.

Windows에서 DNS를 변경한 뒤 ipconfig /flushdns를 실행하면 시스템 캐시를 지울 수 있습니다. 클라이언트 커널과 브라우저의 캐시는 별도로 지워야 할 수 있습니다. ‘사이트 IP 주소로 직접 접속’하는 방법으로 전체 테스트를 대신하지 마세요. HTTPS 사이트는 인증서 검증, SNI, 가상 호스트 선택에 도메인을 사용하므로 IP 직접 접속에 실패해도 DNS와는 무관할 수 있습니다.

6. 시스템 프록시가 정상인 것을 확인한 뒤 TUN 점검하기

프록시 직접 지정과 브라우저의 시스템 프록시는 모두 정상인데 TUN을 켰을 때만 인터넷이 끊긴다면 가상 네트워크 어댑터, 라우팅, DNS 가로채기를 중점적으로 점검하세요. TUN은 가상 네트워크 어댑터로 라우팅되는 IP 트래픽을 가로채는 기능이며 모든 앱과 네트워크 환경에서 자동으로 올바르게 설정된다는 보장은 없습니다. 권한 부족, 드라이버 오류, 다른 VPN이 설치한 경로 때문에 트래픽이 잘못된 인터페이스로 나갈 수 있습니다.

  • 권한 및 서비스: 클라이언트에서 요구하는 서비스 모드나 관리자 권한 승인이 완료됐는지 확인하고, 커널에서 TUN이 성공적으로 시작됐다고 표시하는지 확인하세요.
  • 라우팅 충돌: 다른 VPN 연결을 잠시 끊은 다음 Windows의 route print 또는 macOS의 netstat -rn을 사용해 TUN을 켜기 전과 후의 라우팅을 비교하세요.
  • DNS 가로채기: 설정의 dns-hijack이 실제 DNS 경로와 일치하는지 확인하세요. 일반적인 53번 포트를 가로채면 브라우저의 DoH도 가로챌 수 있다고 단정하지 마세요.
  • IPv6 경로: 도메인이 A와 AAAA 레코드를 모두 반환한다면 IPv4와 IPv6의 라우팅 및 가로채기 상태를 각각 확인하세요. IPv4 테스트가 성공했다는 이유만으로 모든 트래픽이 정상이라고 판단하지 마세요.

웹페이지는 열리지만 큰 이미지나 다운로드가 자주 멈춘다면 패킷 손실, MTU, 프로토콜 차이도 살펴볼 수 있습니다. 다만 이는 프록시 진입 경로, 규칙, DNS가 모두 정상임을 확인한 뒤에 점검할 항목입니다. 근거 없이 MTU부터 바꾸면 변수가 늘어나 원래 문제를 재현하기 어려워질 수 있습니다.

7. 특정 사이트만 실패한다면 상위 연결과 브라우저 확인하기

여러 브라우저에서 같은 사이트에 접속할 수 없지만 다른 사이트는 정상이라면 다른 노드로 같은 사이트에 접속해 보세요. 구독 상태, 노드 프로토콜 매개변수, 시스템 시간도 확인하세요. 시스템 시간이 맞지 않으면 TLS 인증서 검증이 실패할 수 있습니다. 구독 업데이트에 성공했다는 것은 설정을 가져왔다는 뜻일 뿐, 모든 노드를 계속 사용할 수 있다는 뜻은 아닙니다.

브라우저 하나에서만 문제가 발생한다면 확장 프로그램을 사용하지 않는 새 프로필로 비교한 뒤 별도 프록시 설정, 보안 DNS, 캐시, 사이트 권한을 확인하세요. 시크릿 창에서도 시크릿 모드 실행이 허용된 일부 확장 프로그램은 계속 작동할 수 있으므로, 시크릿 모드 테스트만으로 모든 확장 프로그램을 배제할 수는 없습니다. 인증서 오류가 발생하면 오류 코드와 인증서 발급자를 기록하세요. 출처를 알 수 없는 루트 인증서를 설치해 경고를 없애려 하지 마세요.

노드 지연 시간은 짧은데 웹페이지가 느리다면 대상 사이트까지의 거리, 패킷 손실, 대역폭, 서버 측 속도 제한이 원인일 수 있습니다. 한 번의 지연 시간 테스트만으로 실제 웹페이지 요청 결과를 판단할 수는 없습니다. 같은 URL, 같은 네트워크, 같은 시간대에 비교하고 테스트 대상을 바꾼 뒤 생긴 차이를 방금 변경한 설정의 영향으로 단정하지 마세요.

8. 점검 결과를 정리하고 평소 설정으로 복원하기

점검이 끝나면 규칙 모드로 되돌리고 개선 효과가 없었던 임시 변경을 취소하세요. 시스템 프록시 포트가 클라이언트 포트와 일치하는지 확인한 뒤 TUN을 사용할지 결정하세요. 클라이언트를 종료한 뒤 인터넷이 전혀 되지 않는다면 네트워크 전체를 바로 초기화하지 말고, 시스템 프록시가 중지된 로컬 포트를 계속 가리키는지 먼저 확인하세요.

추가 지원을 요청할 때는 ‘연결은 됐는데 열리지 않아요’라고만 알리는 것보다 재현 가능한 정보를 제공하는 것이 도움이 됩니다. 아래 항목을 정리하고 구독 링크, 액세스 토큰, 노드 비밀번호, 개인 IP 주소와 그 밖의 민감한 정보는 가리세요.

  • 운영체제, 클라이언트, 커널의 정확한 버전과 시스템 프록시 또는 TUN 사용 여부
  • 접속에 실패한 대상 도메인과 브라우저 오류 코드. 로그인 토큰이 포함된 전체 URL은 공개하지 마세요.
  • 로컬 수신 포트, 프록시 직접 지정 테스트 결과, 직접 연결 정상 여부
  • 같은 요청에 적용된 규칙, 정책 그룹, 최종 출구, 해당 시간대의 오류 로그
  • 노드 전환, TUN 끄기, 네트워크 변경 후 달라진 결과

권장 순서는 항상 로컬 네트워크 → 프록시 진입 경로 → 수신 포트 → 규칙 출구 → DNS → TUN 및 상위 연결입니다. 한 번에 한 항목만 바꾸고 같은 요청으로 확인해야 ‘정상처럼 보이는’ 상태를 실제 연결 결과와 연결해 설명할 수 있습니다.