프록시 연결됨으로 표시되지만 웹페이지가 열리지 않을 때: 시스템 프록시·DNS·규칙 점검 체크리스트

1. 클라이언트 상태와 실제 요청을 구분하기

Clash 계열 클라이언트에 ‘연결됨’이라고 표시되어도 Mihomo 코어가 실행 중이거나 시스템 프록시가 켜져 있거나 Android VPN 인터페이스가 연결되었다는 뜻일 수 있습니다. 이 상태만으로 브라우저 요청이 코어에 전달되거나 현재 노드가 대상 웹사이트에 연결된다고 단정할 수는 없습니다. ‘앱 → 로컬 프록시 포트 → 규칙 및 정책 그룹 → 아웃바운드 노드 → 대상 서비스’ 순서로 각 구간을 확인하세요.

먼저 다음 세 가지를 기록하세요. 모든 사이트가 열리지 않는지, 일부만 실패하는지; 브라우저만 실패하는지, 다른 앱도 실패하는지; 프록시를 끄면 원래 직접 접속되던 사이트가 다시 열리는지 확인합니다. 조건이 다른 사이트를 섞어 테스트하지 않도록 동일한 전체 URL을 사용하세요.

2. 시스템 프록시가 실제로 Mihomo를 가리키는지 확인

시스템 프록시는 시스템 설정을 따르는 앱에 사용할 프록시 주소를 알려줄 뿐, 모든 프로그램의 트래픽을 자동으로 가로채지는 않습니다. 일부 브라우저 확장 프로그램, 터미널 도구, 게임 및 다른 VPN 소프트웨어는 자체 네트워크 설정을 사용할 수 있습니다. 브라우저 프록시 확장 프로그램과 다른 프록시 클라이언트를 잠시 끄고 프록시 진입점 하나만 사용하세요.

시스템 메뉴와 로컬 주소 확인

• Windows 11: ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’를 열고 ‘수동 프록시 설정’의 주소와 포트를 확인합니다. 구성 스크립트를 사용한다면 브라우저 트래픽이 여전히 해당 스크립트를 따르는지도 확인하세요.
• macOS: ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 서비스 → ‘세부사항’ → ‘프록시’를 열고 웹 프록시, 보안 웹 프록시 또는 SOCKS 프록시 설정을 확인합니다. 메뉴 이름은 시스템 버전에 따라 조금 다를 수 있습니다.
• Android: 시스템에 VPN 표시가 나타나면 VpnService 인터페이스가 생성된 것입니다. 클라이언트의 앱별 프록시 설정에서 브라우저가 제외되어 있지 않은지도 확인하세요.

아래 예시에서는 127.0.0.1:7890을 로컬 혼합 프록시 주소로 사용합니다. 7890은 예시일 뿐 모든 클라이언트의 고정 포트가 아닙니다. 현재 적용 중인 설정이나 클라이언트의 포트 설정에서 실제 값을 확인하세요. external-controller는 제어 인터페이스이므로 웹 프록시 포트로 사용할 수 없습니다.

시스템 설정을 거치지 않고 프록시를 직접 지정해 테스트

Windows PowerShell에서는 curl.exe를 사용하세요. 이전 환경에서 같은 이름으로 지정된 명령 별칭과의 차이를 피할 수 있습니다. macOS와 Linux에서는 아래 명령의 curl.exe를 curl로 바꾸면 됩니다. 예시 대상은 https://example.com/입니다. 현재 네트워크에서 접속할 수 없다면 접속이 확인된 HTTPS 주소로 바꾸세요.

curl.exe -v --connect-timeout 10 --max-time 20 --noproxy "" -x http://127.0.0.1:7890 https://example.com/ -o NUL

macOS와 Linux에서는 출력 대상을 NUL에서 /dev/null로 바꾸세요. --noproxy ""는 환경에 설정된 우회 목록이 명시적 프록시 테스트에 영향을 주지 않도록 합니다. 제한 시간은 각각 10초와 20초로 설정했으며, 이는 문제 해결을 위한 값이지 노드 속도를 측정한 결과가 아닙니다.

• 명령은 성공하지만 브라우저에서 실패한다면 시스템 프록시, 브라우저 확장 프로그램, 별도 프록시 설정, 연결 캐시를 우선 확인하세요.
• 127.0.0.1에 연결할 수 없다는 메시지가 나오면 먼저 로컬 포트를 확인하세요. DNS를 바로 바꿀 필요는 없습니다.
• CONNECT에 성공한 뒤 TLS 또는 원격 연결 오류가 발생한다면 프록시 진입점까지는 연결된 것입니다. 아웃바운드 연결을 계속 점검하세요.

3. 포트 충돌 및 코어 시작 실패

클라이언트 창이 열렸다고 해서 코어가 설정을 정상적으로 불러왔다는 뜻은 아닙니다. 코어 로그에 address already in use, 설정 파싱 실패, 규칙 세트 로드 오류 또는 권한 오류가 있는지 확인하세요. 로컬 포트를 이전 프로세스가 사용 중이면 브라우저가 다른 프록시 프로그램에 연결되었을 수도 있습니다.

포트를 사용하는 프로세스 확인

Windows PowerShell에서 TCP 리스닝 포트를 조회한 다음, 표시된 프로세스 ID로 프로그램을 확인할 수 있습니다. 아래 명령은 조회만 하며 프로세스를 종료하지 않습니다.

Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

Get-Process -Id 1234

1234는 예시 프로세스 ID입니다. 두 번째 명령을 실행하기 전에 첫 번째 명령에서 실제로 반환된 OwningProcess 값으로 바꾸세요. macOS에서는 lsof -nP -iTCP:7890 -sTCP:LISTEN을, Linux에서는 ss -lntp 'sport = :7890'을 실행하면 됩니다. 다른 사용자의 프로세스 정보를 보려면 해당 권한이 필요할 수 있습니다.

시스템 프록시와 실제 적용 설정을 일치시키기

# 로컬 혼합 프록시 예시: 관련 필드 설명용
mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule

이 내용은 전체 구독 설정이 아니므로 노드나 규칙을 덮어쓰는 데 사용하지 마세요. 포트를 7891로 바꾸면 시스템 프록시와 테스트 명령도 함께 변경해야 합니다. 일부 클라이언트는 덮어쓰기 또는 설정 병합을 통해 최종 파일을 생성하므로 구독 원문만 확인하지 말고 ‘실제 적용 설정’을 확인하세요. 로컬 진입점을 제한하려면 루프백 주소를 유지하면 됩니다. 로컬 인터넷 문제를 해결하려고 LAN 접속을 허용할 필요는 없습니다.

4. DNS 문제 해결: 대상 도메인과 노드 도메인 구분

‘DNS 오류’는 크게 두 가지 경우로 나뉩니다. 대상 웹사이트의 도메인을 조회하지 못하거나 프록시 서버 자체의 도메인을 조회하지 못하는 경우입니다. 후자의 경우 웹사이트 도메인의 DNS 응답이 정상이어도 여러 사이트에서 동시에 시간 초과가 발생할 수 있습니다. 로그에서 오류가 발생한 구체적인 도메인을 기록하세요. timeout만 보고 노드가 작동하지 않는다고 판단하지 마세요.

시스템 DNS 조회 결과를 확인한 뒤 코어 로그 확인

nslookup example.com

nslookup은 일반적으로 시스템에서 선택한 DNS 서버에 질의합니다. TUN 가로채기나 네트워크 리디렉션이 적용되면 요청이 다른 경로로 전달될 수도 있습니다. 따라서 이 결과만으로 Mihomo의 모든 DNS 조회 경로를 판단할 수는 없습니다. 브라우저의 보안 DNS, 시스템 암호화 DNS, 코어 내장 DNS도 각각 다른 경로를 사용할 수 있습니다.

• DNS 활성화 여부 확인: 실제 적용 설정에서 dns.enable 상태와 nameserver가 현재 네트워크에서 접속 가능한지 확인하세요.
• 암호화 DNS의 의존성 확인: DoH 또는 DoT 업스트림에서 도메인 주소를 사용한다면 부트스트랩 DNS 조회 경로가 필요합니다. default-nameserver는 DNS 서버 도메인을 조회하는 데 사용할 수 있으므로 업스트림 주소와의 관계를 함께 확인하세요.
• 프록시 노드의 도메인 조회 확인: proxy-server-nameserver는 프록시 노드 도메인을 조회하는 설정입니다. 이를 지정했다면 해당 DNS 서버가 정상적으로 작동하는지 확인하세요. 노드 연결을 시작하기도 전에 같은 노드에 조회를 의존하는 상황은 피해야 합니다.
• 규칙 의존성 확인: respect-rules 등 DNS 연결에 라우팅 규칙을 적용하는 설정을 사용하는 경우 관련 프록시와 직접 연결 DNS 서버도 함께 점검하세요. DNS 조회와 프록시가 서로를 필요로 하는 순환 의존을 방지해야 합니다.

Fake-IP에서 다른 DNS 모드로 전환한 뒤에도 앱에 이전 주소가 남아 있을 수 있습니다. Windows에서는 ipconfig /flushdns를 실행해 시스템 캐시를 비운 다음 브라우저를 완전히 종료하고 다시 여세요. 시스템 캐시를 비워도 브라우저 자체 캐시, DoH 캐시, 이미 연결된 세션까지 모두 지워지는 것은 아닙니다. 요청을 새로 보내고 로그와 대조하세요.

DNS 모드, 모든 업스트림 서버, TUN 설정을 한꺼번에 바꾸지 마세요. 먼저 정상 작동이 확인된 DNS 경로 하나를 확인한 뒤 설정을 하나씩 원래대로 복구하세요. 각 설정의 의미는 DNS 설정 안내에서 확인할 수 있습니다.

5. 규칙 매칭과 정책 그룹: 모드가 아닌 실제 연결 경로 확인

Mihomo의 규칙 모드는 설정된 순서대로 규칙을 확인합니다. 일반적으로 먼저 매칭된 규칙이 요청의 경로를 결정하고, 마지막의 MATCH는 앞선 규칙에 매칭되지 않은 요청을 처리합니다. 대상 도메인이 앞쪽 규칙에서 DIRECT로 지정되면 뒤에 있는 프록시 규칙은 경로를 바꾸지 않습니다.

연결 세부 정보에서 다음 네 항목 확인

1. 대상 도메인과 포트가 방금 테스트한 사이트와 일치하는지 확인하세요. HTTPS는 일반적으로 TCP 443을 사용합니다.
2. 매칭된 규칙의 유형과 내용, 특히 도메인 규칙, 규칙 세트, 기본 규칙을 확인하세요.
3. 매칭된 정책 그룹과 해당 그룹에서 최종 선택한 노드 또는 DIRECT를 확인하세요.
4. DNS 조회, 연결 시도, 프록시 핸드셰이크, TLS 중 어느 단계에서 실패했는지 확인하세요.

클라이언트에서 연결 목록을 비우거나 테스트 시간을 기록한 다음 대상 웹페이지를 다시 여세요. 기존 연결이 재사용되어 결과를 구분하기 어렵다면 해당 연결을 종료한 뒤 재시도하세요. 정책 그룹은 선택을 위한 첫 단계일 뿐, 그룹 안에 다른 그룹이 중첩될 수 있으므로 최종 연결 경로까지 추적해야 합니다.

글로벌 모드는 잠깐 비교할 때만 사용

글로벌 모드로 잠시 전환하고 노드 하나를 직접 선택하세요. 같은 사이트가 글로벌 모드에서는 열리고 규칙 모드에서는 실패한다면 규칙 순서와 정책 그룹 선택을 집중적으로 확인하세요. 두 모드 모두 실패한다면 노드와 네트워크를 점검하세요. 글로벌 모드로 고장 난 노드가 복구되거나 코어에 전달되지 않은 앱 트래픽까지 자동으로 처리되는 것은 아닙니다.

규칙 세트 다운로드 실패도 설정 로드나 트래픽 분기에 영향을 줄 수 있습니다. rule-providers 업데이트 로그와 로컬 캐시 상태를 확인하세요. 웹페이지를 잠시 열기 위해 전체 규칙을 삭제하지 말고, 실제로 매칭된 항목을 찾아 필요한 규칙 순서나 정책만 조정하세요. 문제 해결 후에는 원래 규칙 모드로 복구합니다.

6. 노드 상태 확인: 지연 시간이 표시돼도 웹사이트 접속이 보장되지는 않음

지연 시간 테스트 결과는 지정된 테스트 URL을 현재 네트워크에서 특정 시점에 확인한 값입니다. 지연 시간이 표시되더라도 다른 도메인, 동영상 서비스, UDP 트래픽까지 모두 연결된다는 뜻은 아닙니다. 노드 목록에 항목이 보여도 구독에 포함된 주소, 포트, 인증 정보가 여전히 유효하다는 보장은 없습니다.

• 같은 네트워크에서 노드 변경: 브라우저, 대상 URL, 프록시 모드는 그대로 두고 노드만 바꾸세요. 다른 노드에서 바로 접속된다면 기존 노드나 서버 상태를 먼저 확인하세요.
• 같은 노드에서 네트워크 변경: Wi-Fi에서 모바일 핫스팟으로 전환한 뒤 같은 사이트에 접속하세요. 결과가 달라진다면 접속 네트워크의 DNS, 방화벽, 라우팅 조건을 추가로 확인할 필요가 있습니다.
• 구독 업데이트 시간 확인: 업데이트가 성공했는지, 이전 캐시를 계속 사용 중인지 확인하세요. 업데이트한 뒤에도 클라이언트 덮어쓰기 설정이 노드 관련 항목을 덮어쓰는지 점검해야 합니다.
• 프로토콜 설정 확인: 수동으로 설정했다면 서버 주소, 포트, 인증 정보, TLS 서버 이름, 전송 설정을 확인하세요. 필요한 항목은 프로토콜마다 다르므로 다른 프로토콜의 설정을 그대로 조합해서는 안 됩니다.

connection refused는 대상 포트에서 연결을 받지 않거나 연결이 명시적으로 거부된 경우에 흔히 나타납니다. i/o timeout은 응답을 기다리다 시간 초과된 상태로, 이 메시지만으로 서버 오류인지 중간 네트워크의 패킷 손실인지 판단할 수 없습니다. 인증서 오류가 발생하면 시스템 시간, 대상 도메인, TLS 설정을 확인하세요. 핸드셰이크 오류를 감추기 위해 인증서 검증을 계속 건너뛰지 마세요.

로그인 페이지나 특정 사이트만 실패한다면 사이트가 반환한 HTTP 상태 코드도 확인하세요. 403, 429 또는 계정 제한은 ‘로컬 프록시 포트가 시작되지 않음’과는 다른 문제입니다. 응답이 실제 대상 서비스에서 온 것인지 확인한 뒤 출구 IP 정책이나 사이트 자체 제한을 살펴보세요.

7. TUN, 앱별 프록시, 브라우저 프로토콜 추가 점검

프록시를 명시한 HTTP 테스트는 정상인데 TUN을 켜면 접속할 수 없는 경우, 문제 범위를 좁히는 중요한 단서가 됩니다. TUN은 가상 네트워크 어댑터, 라우팅, 권한에 의존합니다. tun.auto-route, 인터페이스 감지, DNS 가로채기를 켰다면 다른 VPN, 가상 머신 네트워크, 보안 소프트웨어와 충돌하는지도 확인하세요.

데스크톱에서 먼저 TUN 경로 분리

1. 현재 TUN 및 시스템 프록시 상태를 기록한 뒤 TUN을 잠시 끄세요.
2. 앞서 안내한 프록시 지정 명령만 사용해 같은 URL을 테스트하고 로컬 진입점과 노드 연결을 확인하세요.
3. 프록시 지정 테스트가 정상이라면 TUN을 다시 켜고 시작 로그에서 권한, 네트워크 어댑터 생성, 라우팅 설정 결과를 확인하세요.
4. 클라이언트를 종료한 뒤에도 직접 연결되지 않으면 남아 있는 시스템 프록시 설정, 다른 VPN, 라우팅을 확인하세요. 시스템 라우팅 테이블을 무작정 삭제하지 마세요.

Android에서 앱 트래픽이 프록시를 거치는지 확인

Android에서는 일반적으로 일반 앱의 VPN 서비스를 한 번에 하나만 활성화할 수 있습니다. 다른 VPN, 광고 차단 VPN 또는 업무 프로필의 네트워크 도구로 전환하면 기존 클라이언트가 대체될 수 있습니다. 앱별 설정에서 ‘선택한 앱만 프록시 사용’과 ‘선택한 앱 우회’는 의미가 반대이므로 브라우저가 의도한 목록에 있는지 확인하세요. 화면을 잠근 뒤에만 문제가 발생한다면 규칙을 먼저 다시 작성하지 말고 백그라운드 제한과 배터리 최적화를 확인하세요.

브라우저에서만 실패한다면 HTTP/3 확인

HTTP/3은 QUIC을 사용하며 일반적으로 UDP 443을 이용합니다. 프록시를 지정한 HTTP 명령이 성공해도 브라우저의 QUIC 연결이 정상이라는 뜻은 아닙니다. 문제가 브라우저에만 나타나는 것이 분명하다면 HTTP/3을 잠시 끄고 비교해 보세요. 결과가 달라지는 경우에만 UDP 아웃바운드, 노드 지원 여부, TUN 연결을 점검하세요. 모든 웹페이지 문제에 HTTP/3 비활성화를 일률적인 해결책으로 적용하지 마세요.

8. 설정 복원 및 문제 제보에 필요한 최소 정보

문제가 발생한 구간을 찾았다면 테스트를 위해 임시 변경한 글로벌 모드, DNS 업스트림, 브라우저 프로토콜 설정을 하나씩 복구하고 실제로 문제를 해결한 변경 사항만 유지하세요. 직접 접속할 사이트 하나, 프록시가 필요한 사이트 하나, 원래 실패했던 대상을 다시 테스트합니다. 마지막으로 클라이언트를 종료했을 때도 시스템이 예상대로 인터넷에 연결되는지 확인하세요.

문제를 계속 제보해야 한다면 ‘연결됨’ 스크린샷 한 장만 보내는 것보다 다음 정보를 제공하는 편이 원인 파악에 도움이 됩니다. 로그는 재현 전후의 필요한 부분만 첨부하고 구독 정보, 노드 비밀번호, 제어 인터페이스 토큰은 공개하지 마세요.

• 운영체제 및 클라이언트 버전, 실제 Mihomo 코어 버전, 클라이언트 덮어쓰기 사용 여부
• 시스템 프록시 또는 TUN 활성화 상태, 로컬 리스닝 주소와 포트, 앱별 프록시 설정
• 문제 발생 시각, 대상 도메인, 사용 중인 네트워크, 모든 대상에서 문제가 발생하는지 여부
• 프록시를 명시한 명령의 결과, 실제 매칭 규칙, 최종 정책 그룹과 노드
• 노드 변경, 네트워크 변경, TUN 끄기 중 결과가 달라진 단계