프록시 연결됨인데 웹페이지가 열리지 않을 때: 10가지 점검 항목

Clash 클라이언트에서 ‘연결됨’으로 표시되더라도 커널이 실행 중이거나 시스템 프록시가 켜져 있거나 VPN 인터페이스가 만들어졌다는 뜻일 수 있습니다. 대상 웹사이트 접속에 성공했다는 의미는 아닙니다. 노드 지연 시간에 숫자가 표시되어도 특정 시점에 테스트 요청이 완료됐다는 것만 알 수 있습니다. 문제를 해결하려면 연결 과정을 나눠서 확인해야 합니다. 앱의 트래픽이 프록시로 들어가는지, 규칙에 맞는 출구가 선택됐는지, 노드 연결이 가능한지, 도메인 이름이 올바르게 조회되는지 차례로 살펴보세요.

01｜기본 네트워크와 오류 범위 확인

시스템 프록시와 TUN을 끈 다음, 평소에 프록시 없이 접속되는 웹사이트를 열어 보세요. 그래도 접속되지 않는다면 Wi-Fi, 유선 연결, 라우터, 통신사 또는 학교 네트워크 인증부터 확인해야 합니다. 이 경우 구독을 반복해서 업데이트해도 대개 해결되지 않습니다. 호텔이나 공항 같은 공용 네트워크는 브라우저에서 먼저 포털 인증을 해야 할 수 있습니다. 프록시를 사용하면 이 인증 단계가 복잡해질 수 있습니다.

1. 자주 이용하는 한국 사이트와 기존에 접속되지 않던 사이트를 각각 테스트하고, 모든 사이트에서 실패하는지 일부만 실패하는지 기록하세요.
2. 현재 네트워크 대신 휴대폰 핫스팟을 사용하되 클라이언트, 설정, 노드는 그대로 유지하세요. 핫스팟에서는 정상이고 기존 네트워크에서만 실패한다면 해당 네트워크의 제한을 우선 확인하세요.
3. 시스템 시간, 시간대, 날짜가 올바른지 확인하세요. 시간이 크게 어긋나면 TLS 인증서 유효기간 오류가 발생할 수 있습니다.

ping만으로 웹사이트 접속 여부를 판단하지 마세요. 대상 서버에서 ICMP를 차단할 수 있으며, 브라우저는 실제로 TCP 443이나 QUIC을 사용할 수 있습니다. 반대로 IP 주소에 ping이 성공해도 HTTPS, 인증서, 프록시 연결이 정상이라는 뜻은 아닙니다.

02｜구독 유효기간과 설정 적용 여부 확인

클라이언트의 ‘구독’ 또는 ‘설정’ 페이지에서 현재 구독을 직접 업데이트한 뒤 업데이트 로그를 확인하세요. 다운로드 성공, 파싱 성공, 설정 전환 성공은 각각 구분해야 합니다. 구독 URL에서 내용을 받아 왔다고 해서 커널이 해당 YAML을 읽을 수 있다는 뜻은 아닙니다. 로그인 페이지, 잔여 사용량 안내 또는 오류 문구가 반환되면 설정 파싱에 실패할 수 있습니다.

• HTTP 401 또는 403: 인증 정보, 구독 토큰, 서비스 계정 상태를 확인하세요. 상태 코드만 보고 구독이 만료됐다고 단정하면 안 됩니다.
• HTTP 200이지만 파싱 오류 발생: 응답 콘텐츠 유형과 구독 형식을 확인하고, 클라이언트 커널이 해당 프로토콜과 필드를 지원하는지 살펴보세요.
• 목록에 이전 노드가 남아 있음: 기존 설정이 로컬에 남아 있을 수 있습니다. 노드가 보인다고 구독이 유효한 것은 아니므로 유효기간과 잔여 트래픽도 확인하세요.
• 업데이트 후에도 노드가 그대로임: 방금 업데이트한 설정이 현재 활성화되어 있는지 확인하세요. proxy-providers를 사용하는 경우 해당 제공자의 업데이트 결과도 살펴보세요.

03｜노드 연결 확인: 지연 시간만으로 판단하지 않기

노드 하나를 고정 선택해 테스트 중 자동 선택 그룹이 출구를 바꾸지 않도록 하세요. 같은 대상을 3회 연속 테스트한 다음, 다른 지역이나 회선의 노드로 바꿔 비교하세요. 특정 노드 하나만 실패하면 우선 해당 노드를 확인하세요. 같은 서비스 제공업체의 모든 노드가 실패한다면 계정, 네트워크, 커널 호환성을 이어서 점검하세요.

지연 시간 테스트는 보통 지정된 테스트 URL에 요청을 보냅니다. 성공하더라도 해당 URL에 그 시점에 접속할 수 있었다는 뜻일 뿐입니다. 대상 웹사이트에는 별도의 접속 제한이 있을 수 있고, 노드도 사용량이 많은 시간대에만 패킷 손실이 발생할 수 있습니다. 로그에서 ‘노드 서버 연결’과 ‘노드에서 대상 접속’ 중 어느 단계가 실패했는지 확인하세요. 두 오류는 발생 계층이 다릅니다.

• connection refused: 연결이 명시적으로 거부됐습니다. 서버 포트, 서비스 상태, 로컬 리스닝 상태를 확인하세요.
• i/o timeout: 연결 또는 데이터 읽기·쓰기가 시간 초과됐습니다. 오류에 표시된 주소를 보고 노드, DNS, 대상 중 어디에서 발생했는지 확인하세요.
• TLS 핸드셰이크 실패: 시간, SNI, 프로토콜 매개변수, 커널 지원 여부를 확인하세요. 인증서 검증을 바로 끄지는 마세요.

04｜시스템 프록시와 mixed-port 일치 여부 확인

클라이언트는 정상처럼 보이는데 브라우저 요청 로그가 남지 않을 때 자주 발생하는 원인입니다. 먼저 현재 적용된 설정의 mixed-port 값을 확인하세요. 기본 포트를 추측하면 안 됩니다. 아래 예시는 7890을 사용합니다. 실제 값이 7897이라면 시스템 설정과 테스트 명령도 모두 같은 값으로 바꿔야 합니다.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

Windows 11에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’ → ‘수동 프록시 설정’에서 주소와 포트를 확인할 수 있습니다. macOS에서는 ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 → ‘세부사항’ → ‘프록시’에서 확인하세요. 클라이언트가 시스템 프록시를 관리한다면 클라이언트의 설정을 우선 사용해 양쪽 설정이 서로 덮어쓰지 않게 하세요. external-controller는 관리 인터페이스이며 웹 프록시 포트로 사용할 수 없습니다.

브라우저 설정을 거치지 않고 프록시 연결 테스트하기

Windows에서는 터미널에서 curl.exe를 사용하고, macOS와 Linux에서는 명령어를 curl로 바꾸세요. 다음 명령은 최대 20초 동안 기다린 뒤 응답 헤더만 출력하며 웹페이지 전체를 다운로드하지 않습니다.

curl.exe -I --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/

HTTP 응답을 받았다면 요청이 최소한 HTTP 응답을 보내는 서버까지 도달한 것입니다. 403은 페이지를 정상적으로 사용할 수 있다는 뜻이 아닙니다. 200 Connection established가 표시된 뒤 TLS 오류가 발생했다면 프록시 터널이 만들어졌다는 의미일 뿐, HTTPS 접속 성공 여부는 아직 확인되지 않았습니다. 프록시를 명시한 테스트는 성공하지만 브라우저에서 실패한다면 브라우저 프록시 설정, 확장 프로그램, 보안 DNS를 확인하세요. 로컬 포트에 연결할 수 없다면 커널과 리스닝 상태부터 점검하세요.

# Windows PowerShell: 7890 포트를 사용하는 프로세스 확인
Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

# Linux: 리스닝 포트와 프로세스 확인
ss -lntp 'sport = :7890'

# macOS: 리스닝 포트와 프로세스 확인
lsof -nP -iTCP:7890 -sTCP:LISTEN

해당 포트를 현재 클라이언트 커널이 사용 중인지 확인하세요. 다른 프로그램이 먼저 포트를 점유했다면 충돌하는 프로그램을 종료하거나 프록시 포트를 변경하세요. 프로세스 번호가 보인다고 바로 해당 프로세스를 종료하면 안 됩니다.

05｜앱이 시스템 프록시를 우회하는지 확인

시스템 프록시는 모든 프로그램에 적용되는 전역 스위치가 아닙니다. 일부 게임, 명령줄 도구, 자체 네트워크 스택을 사용하는 소프트웨어는 시스템 프록시를 읽지 않습니다. 브라우저 확장 프로그램도 별도의 프록시 설정을 사용할 수 있습니다. 요청을 보냈을 때 클라이언트의 ‘연결’ 페이지나 로그에 해당 대상이 기록되는지 확인하세요.

• 브라우저: 프록시 전환 확장 프로그램을 잠시 사용 중지하고, 별도의 SOCKS 주소나 우회 목록이 설정되어 있지 않은지 확인하세요.
• 명령줄: HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NO_PROXY 환경 변수를 확인해 오래된 포트나 제외 규칙이 의도한 설정을 덮어쓰지 않는지 살펴보세요.
• Firefox: ‘설정’ → ‘일반’ → ‘네트워크 설정’ → ‘설정’에서 시스템 프록시를 사용하는지 수동 프록시를 사용하는지 확인하세요.

PowerShell에서는 Get-ChildItem Env:*proxy*로 관련 환경 변수를 확인할 수 있습니다. macOS와 Linux에서는 env | grep -i proxy를 사용하세요. 출력에 인증 정보가 포함될 수 있으므로 공유 전에 가리세요. VPN, 프록시 확장 프로그램, 네트워크 가속 도구를 여러 개 동시에 켜지 마세요. 데이터 패킷은 환승하는데 문제 해결 기록에는 어느 정류장인지 남지 않을 수 있습니다.

06｜TUN 권한, 서비스, 라우팅 점검

프록시를 명시한 HTTP 연결은 정상이지만 TUN을 켰을 때만 인터넷이 끊긴다면 노드보다는 가상 네트워크 어댑터, 라우팅, 권한을 확인해야 합니다. Windows 클라이언트는 보통 서비스 모드나 관리자 권한이 필요합니다. Linux에서는 필요한 네트워크 관리 권한을 확인하고, macOS에서는 클라이언트 안내에 따라 네트워크 구성 요소를 승인해야 합니다. 필요한 권한은 사용 중인 클라이언트의 안내를 기준으로 확인하세요.

1. TUN을 끄고 시스템 프록시나 명시적 프록시로 정상 접속되는지 확인해 비교 기준을 만드세요.
2. 커널 로그에서 가상 네트워크 어댑터 생성 실패, 권한 부족, 라우트 추가 실패 등의 오류를 확인하세요.
3. 다른 VPN이나 가상 네트워크 프로그램을 잠시 종료한 뒤 TUN을 켜고 기본 경로가 바뀌는지 확인하세요.
4. Android에서는 시스템 ‘설정’에서 ‘VPN’을 검색해 대상 클라이언트에 현재 권한이 부여되어 있는지 확인하세요. 상시 연결 VPN과 VPN 미사용 연결 차단 설정이 함께 적용되면 전환에 영향을 줄 수 있습니다.

mihomo의 tun.enable, auto-route, dns-hijack는 각각 인터페이스 활성화, 라우팅, DNS 가로채기와 관련된 설정입니다. 첫 번째 항목을 켰다고 나머지까지 자동으로 올바르게 설정되는 것은 아닙니다. 클라이언트가 이 필드들을 병합해 생성할 수 있으므로 구독 원문만 보지 말고 최종 실행 설정을 확인하세요.

07｜규칙 모드, 정책 그룹, REJECT 적용 여부 확인

‘연결’ 페이지에서 실패한 도메인을 찾아 적용된 규칙, 정책 그룹, 최종 노드를 확인하세요. 규칙은 순서대로 평가되며 일치하는 규칙을 찾으면 처리가 끝납니다. 특정 도메인이 앞쪽 규칙에서 DIRECT 또는 REJECT로 처리되면 뒤에 있는 기본 규칙은 실행되지 않습니다.

잠시 전역 모드로 전환하고 앞서 연결을 확인한 노드를 직접 선택해 보세요. 전역 모드에서는 접속되지만 규칙 모드에서 실패한다면 규칙 순서와 정책 그룹 선택을 집중적으로 확인하세요. 전역 모드는 커널에 들어온 트래픽의 분기 방식만 바꿉니다. 원래 프록시를 우회하던 앱까지 자동으로 처리하지는 않습니다. TUN에서 사설망 및 라우트 제외 설정도 별도로 확인해야 합니다.

# 규칙 예시: PROXY는 설정에 실제로 존재하는 노드 또는 정책 그룹이어야 합니다
rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

위 예시는 규칙 순서를 설명하기 위한 것으로, 전체 규칙을 덮어쓰라는 뜻은 아닙니다. 웹사이트의 기본 도메인은 열리지만 이미지나 로그인이 실패한다면 관련 CDN, API, 인증 도메인도 확인하세요. 수정 후에는 규칙 모드로 되돌리고 필요한 부분만 고치세요. 오류를 가리기 위해 전역 모드를 계속 사용하지 마세요.

08｜DNS 실패, 오염, 암호화 DNS 우회 구분

로그에 도메인 조회 실패나 DNS 시간 초과가 표시되거나, 같은 도메인이 서로 다른 네트워크에서 비정상적으로 다른 결과를 반환할 때 DNS를 확인하세요. CDN은 원래 서로 다른 IP를 반환할 수 있으므로 두 번의 결과가 다르다는 이유만으로 오염이라고 단정할 수 없습니다. 반환된 주소 대역, 연결 오류, 신뢰할 수 있는 DNS 경로로 바꿨을 때의 결과를 함께 살펴보세요.

먼저 DNS 질의가 어느 서버로 전송되는지 확인하세요

# Windows: 시스템 기본 DNS의 응답 확인
nslookup example.com

# mihomo DNS가 실제로 127.0.0.1:1053에서 리스닝할 때만 사용
nslookup -port=1053 example.com 127.0.0.1

# macOS, Linux: dig가 설치되어 있다면 동일한 리스닝 포트를 지정해 확인
dig @127.0.0.1 -p 1053 example.com A

1053은 예시일 뿐입니다. 최종 설정의 dns.listen 값과 일치해야 합니다. 프록시 리스닝 포트인 7890은 DNS 포트가 아닙니다. fake-ip를 사용 중이라면 198.18.0.0/16 대역의 주소가 반환되는 것은 정상적인 매핑 결과일 수 있으며, DNS 오류를 의미하지 않습니다. 중요한 점은 이후 접속이 커널의 처리를 계속 거치는지입니다.

• dns.enable이 활성화되어 있고 상위 DNS 서버에 연결할 수 있는지, 프록시 서버 도메인의 조회 과정에서 의존성 루프가 생기지 않는지 확인하세요.
• TUN의 DNS 가로채기는 일반적으로 53번 포트의 일반 DNS 질의를 대상으로 합니다. 그렇다고 브라우저에 내장된 DoH도 같은 방식으로 처리된다고 볼 수는 없습니다.
• 브라우저 보안 DNS와 Android ‘비공개 DNS’를 테스트 조건에 맞게 잠시 설정하세요. 한 번에 한 항목만 바꾸고 테스트가 끝나면 필요한 설정을 복구하세요.
• Windows에서 DNS를 변경한 뒤 ipconfig /flushdns를 실행하고 브라우저를 다시 시작하세요. 시스템 캐시를 비워도 각 앱의 자체 캐시까지 모두 삭제되는 것은 아닙니다.

respect-rules를 사용하면 DNS 상위 서버 연결에도 라우팅 규칙이 적용됩니다. 이때 proxy-server-nameserver 같은 초기 DNS 조회 설정도 함께 고려해야 합니다. 도메인 하나를 고치려고 여러 fallback과 상위 DNS 설정을 겹쳐 추가하지 마세요. 그러면 어느 DNS 서버가 응답했는지 파악하기 어려워집니다.

09｜IPv6, UDP, MTU의 부분 오류 확인

홈페이지는 열리지만 동영상, 로그인, 용량이 큰 리소스가 계속 로딩된다면 프로토콜 차이를 확인해야 합니다. 클라이언트를 바로 재설치하지 말고 같은 노드와 URL로 비교 테스트하세요. 시스템에 IPv6 주소가 있다고 해서 현재 네트워크와 프록시 출구에서 모두 IPv6를 사용할 수 있는 것은 아닙니다.

기본 네트워크의 직접 연결 테스트에는 curl -4 --noproxy "*" -I --max-time 20 https://example.com/을 사용할 수 있습니다. 다음으로 -4를 -6으로 바꾸세요. Windows에서는 curl.exe를 사용합니다. 대상에 해당 주소 레코드가 있어야 합니다. HTTP 프록시를 통해 테스트할 경우 -4는 원격 프록시가 대상에 IPv4로 연결하도록 강제하지 않습니다. 두 가지 테스트를 혼동하지 마세요.

MTU를 변경할 때는 클라이언트가 최종 설정을 실제 적용했는지 확인하고 TUN을 다시 연결한 뒤 테스트하세요. 개선되지 않으면 원래 값으로 복구하세요. UDP 연결이 안 된다고 해서 모든 웹페이지가 실패하는 것은 아닙니다. 많은 브라우저는 TCP로 전환할 수 있으며, 실제 동작은 네트워크와 앱 구현에 따라 다릅니다.

10｜로그로 원인을 확인하고 최소 재현 절차와 복구 방법 준비

앞의 아홉 항목으로 원인을 찾지 못했다면 짧은 시간 동안 디버그 로그를 켜고 오류를 한 번만 재현한 다음 info로 되돌리세요. 같은 시간대의 앱 연결, 적용된 규칙, 선택한 노드, DNS 조회, 최종 오류를 한 흐름으로 읽을 수 있어야 합니다. 로그의 마지막 ‘시간 초과’ 한 줄만으로는 로컬 리스닝, 노드 연결, 대상 응답 중 어디에서 문제가 발생했는지 구분하기 어렵습니다.

문의 전에 다음 여섯 가지를 정리하세요

1. 운영체제 버전, 클라이언트 버전, mihomo 커널 버전을 각각 기록하세요.
2. 시스템 프록시와 TUN 중 어떤 모드인지, 실제 mixed-port 값은 무엇인지, 다른 VPN을 함께 사용하는지 기록하세요.
3. 같은 URL에 대한 명시적 프록시 테스트 결과, 브라우저 동작, 테스트 시간을 기록하세요.
4. 최종 노드를 포함해 규칙 모드와 전역 모드의 결과를 비교하세요. 정책 그룹 이름만 적어서는 안 됩니다.
5. 현재 네트워크와 휴대폰 핫스팟을 비교하고, 노드나 네트워크를 바꿨을 때 오류가 달라지는지 기록하세요.
6. 민감 정보를 가린 관련 로그와 최소 설정 내용을 첨부하세요. 토큰, 비밀번호, 구독 링크, 사설 주소 정보는 삭제하세요.

YAML 문법과 설정 필드를 확인하려면 동일한 커널 바이너리와 올바른 작업 디렉터리를 사용하는지 확인한 뒤 mihomo -t -f config.yaml을 실행하세요. 설정 검사에 통과했다는 것은 설정을 읽을 수 있다는 뜻일 뿐, 노드, 상위 DNS 서버, 대상 네트워크에 접속할 수 있다는 의미는 아닙니다. 외부 규칙 파일, 데이터베이스, 상대 경로를 사용하는 경우 테스트 환경과 실제 실행 환경도 일치시켜야 합니다.

10가지 점검의 목적은 모든 스위치를 하나씩 바꿔 보는 것이 아닙니다. 기본 네트워크 → 유효한 설정 → 로컬 리스닝 → 앱 트래픽 처리 → 규칙 선택 → DNS와 출구 순서로 각 구간이 정상인지 확인하는 것입니다. 문제가 발생한 구간만 수정하세요. ‘재설치했더니 가끔 해결됐다’는 한 번의 오류를 끝낼 수는 있지만 다음 오류의 원인을 설명해 주지는 못합니다.