Clash 연결됨으로 표시되는데 웹페이지가 열리지 않을 때: 구독·포트·시스템 프록시 점검 가이드

먼저 ‘연결됨’이 어느 구간을 의미하는지 확인하세요

Clash 클라이언트가 실행 중이고 노드에 지연 시간이 표시되거나 시스템에 VPN 연결로 나타나더라도, 브라우저에서 대상 웹사이트까지의 전체 경로가 정상이라는 뜻은 아닙니다. 실행 중 표시는 대개 커널 프로세스가 시작되었다는 의미입니다. 노드 지연 시간 테스트는 보통 설정된 테스트 주소에만 접속하며, Android의 VPN 표시는 주로 로컬 VPN 서비스가 연결되었음을 나타냅니다. 웹페이지에 접속하려면 앱의 프록시 설정, 로컬 수신 포트, 분기 규칙, 노드의 외부 연결, 대상 사이트까지 모두 정상이어야 합니다. 어느 한 구간에 문제가 있어도 페이지가 계속 로딩될 수 있습니다.

이 가이드는 Clash 호환 클라이언트를 대상으로 합니다. Clash Meta(현재 이름은 mihomo) 커널도 같은 순서로 점검할 수 있습니다. 클라이언트마다 설정 이름과 기본 포트가 다를 수 있습니다. 예시에 나오는 7890은 확인을 위한 로컬 혼합 포트일 뿐이므로, 사용 중인 기기의 실제 값으로 간주하지 마세요.

현재 설정 이름, 선택한 노드, 프록시 모드, HTTP 또는 혼합 포트, 시스템 프록시 및 TUN 설정 상태를 기록하세요.
먼저 다른 프록시 클라이언트와 VPN을 일시 중지하세요. 데스크톱에서는 TUN을 끄고 시스템 프록시만 사용해 점검하면 라우팅 및 DNS 변수를 줄일 수 있습니다.
평소 직접 접속할 수 있는 웹사이트와 현재 프록시 경로가 필요한 웹사이트를 각각 열고, 브라우저에 표시된 오류 코드를 빠짐없이 기록하세요.
한 번에 한 항목만 변경한 뒤 같은 주소에 접속하세요. 효과가 있으면 변경 사항을 유지하고, 효과가 없으면 원래대로 되돌리세요. 포트, DNS, 규칙을 한꺼번에 변경하지 마세요.

1단계: 구독 만료 여부와 설정 적용 여부 확인

구독 업데이트에 성공해도 노드가 정상이라는 뜻은 아닙니다

클라이언트의 구독 또는 설정 페이지에서 현재 활성화된 설정을 확인하세요. 목록에서 가장 최근에 업데이트된 항목만 확인해서는 안 됩니다. 업데이트 성공은 구독 데이터를 다운로드할 수 있었다는 의미일 뿐, 계정에 사용 가능한 트래픽이 남아 있거나 노드 서버에 현재 접속할 수 있음을 보장하지 않습니다. 반대로 구독 업데이트에 실패해도 클라이언트가 캐시된 설정을 계속 사용하면 목록에 노드가 표시될 수 있습니다.

계정 확인: 구독 제공업체의 계정 페이지에서 만료일, 잔여 데이터, 기기 제한을 확인하세요. 클라이언트에 표시된 캐시 값만을 기준으로 판단하지 마세요.
응답 확인: 로그에 HTTP 401 또는 403이 표시되면 인증, 계정 상태, 서비스 제공업체의 접속 제한을 확인하세요. 404가 표시되면 주소가 폐기되었거나 복사 과정에서 누락되지 않았는지 확인하세요. 상태 코드만으로 원인을 단정할 수는 없습니다.
형식 확인: YAML 파싱 오류가 발생한다면 로그인 페이지나 오류 페이지가 다운로드되었거나, 현재 클라이언트가 지원하지 않는 Clash 설정 파일일 수 있습니다.
커널 확인: 설정에 현재 커널에서 지원하지 않는 프로토콜이나 필드가 포함되어 있다면 제공업체가 지원한다고 명시한 구독 형식을 선택하거나 호환되는 커널을 사용하세요. 설정을 반복해서 가져오는 것만으로 해결되지는 않습니다.

노드를 고정해 자동 선택 변수 줄이기

현재 정책 그룹에서 노드 하나를 직접 선택하고 요청이 실제로 해당 그룹을 통과하는지 확인하세요. 노드 A와 노드 B를 차례로 테스트하되 매번 같은 웹사이트에 접속합니다. 지연 시간 테스트는 통과했는데 웹페이지가 열리지 않는다면 테스트 사이트에는 접속할 수 있지만 대상 사이트에는 접속할 수 없거나, 대상 사이트 요청이 다른 정책 그룹을 통과하고 있을 수 있습니다. 지연 시간 숫자만 보고 판단하지 말고 연결 기록에서 실제 외부 연결 경로도 확인하세요.

모든 노드에서 접속에 실패하지만 직접 연결 사이트는 정상이라면 구독 계정, 노드 주소 확인, 노드 포트 연결 상태를 먼저 점검하세요. 구독 링크를 낯선 온라인 변환기나 검사 페이지에 입력하지 마세요. 링크에 접속 자격 정보가 포함된 경우가 많으므로 스크린샷을 공유할 때도 토큰과 QR 코드를 가려야 합니다.

2단계: 혼합 포트 수신 상태 확인 및 포트 충돌 점검

시스템 프록시는 127.0.0.1:7890을 가리키는데 커널은 실제로 7897에서 수신 중이라면 브라우저는 해당 경로로 트래픽을 전달할 수 없습니다. 이전 클라이언트가 포트를 계속 사용 중인 경우도 흔합니다. 새 클라이언트 화면은 실행 중으로 표시되더라도 포트 바인딩에 실패해 커널이 프록시 서비스를 제공하지 못할 수 있습니다. 먼저 현재 실행 설정의 mixed-port 또는 HTTP port를 확인하고, 로그에 address already in use가 있는지 살펴보세요.

Windows PowerShell에서 다음 명령을 실행해 예시 포트 7890을 확인하세요. 사용 중인 포트가 다르면 명령의 숫자를 먼저 바꾸세요.

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

수신 결과가 없다면 커널이 시작되었는지, 설정 로드에 실패하지 않았는지 확인하세요. 프로세스 ID를 찾았다면 다음 명령으로 어떤 프로세스인지 확인할 수 있습니다. 정체를 알 수 없는 프로세스를 바로 종료하지 말고, 로컬 프록시를 고치기 위해 수신 주소를 모든 네트워크 인터페이스로 변경하지도 마세요.

Get-Process -Id (Get-NetTCPConnection -State Listen -LocalPort 7890).OwningProcess

브라우저를 거치지 않고 프록시 경로 직접 테스트

Windows에 기본 포함된 curl.exe를 사용해 로컬 HTTP 프록시를 지정하세요. macOS 또는 Linux에서는 같은 옵션으로 curl을 실행할 수 있습니다. 아래 주소는 HTTPS 요청이 완료되는지 확인하기 위한 것으로, 노드 속도를 측정하는 기준은 아닙니다.

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

테스트 결과	우선 확인할 항목	다음 단계
로컬 포트에 연결할 수 없다는 오류가 즉시 표시됨	수신 주소 또는 포트가 잘못되었거나 커널이 시작되지 않음	수신 프로세스와 실행 설정을 다시 확인
로컬 연결 후 시간 초과	외부 노드, 규칙 또는 주소 확인 단계의 문제	같은 시간대의 커널 로그와 대조
대상 웹사이트의 HTTP 응답 헤더 수신	해당 대상으로 지정한 프록시 경로는 정상	브라우저 및 시스템 프록시 설정 확인
프록시 인증 오류 수신	로컬 프록시에 인증이 설정되어 있음	인증 설정과 클라이언트 지원 여부 확인

HTTPS 요청에서 200 Connection established만 확인되었다고 대상 페이지까지 정상적으로 응답했다는 뜻은 아닙니다. 이후 TLS 핸드셰이크와 대상 사이트의 응답도 확인해야 합니다. 대상 사이트에서 403 또는 429를 반환해도 프록시 연결이 끊긴 것은 아닐 수 있습니다. 사이트의 접속 정책이나 요청 빈도 제한 때문일 수 있습니다.

3단계: 시스템 프록시와 브라우저 설정이 일치하는지 확인

지정 프록시 테스트는 성공했는데 브라우저에서 페이지가 열리지 않는다면 브라우저가 실제로 같은 프록시 경로를 사용하는지 확인하세요. 시스템 프록시는 기기 전체의 트래픽을 투명하게 처리하지 않습니다. 앱이 시스템 프록시를 무시하거나 확장 프로그램, PAC 스크립트, 자체 프록시 설정이 이를 덮어쓸 수도 있습니다.

Windows 11: 「설정」→「네트워크 및 인터넷」→「프록시」를 열어 수동 프록시 주소와 포트, 설정 스크립트 사용 여부를 확인하세요. 클라이언트에서 시스템 프록시를 켰다면 트레이 아이콘 상태만 보지 말고 이 화면의 설정을 확인해야 합니다.
macOS: 「시스템 설정」→「네트워크」→ 사용 중인 네트워크 서비스 →「세부사항」→「프록시」를 여세요. HTTP, HTTPS 또는 자동 프록시 설정이 현재 구성과 일치하는지 확인하고, 작동하지 않는 PAC 주소가 함께 남아 있지 않은지 살펴보세요.
Firefox: 「설정」→「일반」→「네트워크 설정」→「설정」을 열어 시스템 프록시 설정 사용이 선택되어 있는지, 또는 다른 프록시가 수동으로 입력되어 있는지 확인하세요.
Android: 일반적으로 클라이언트의 VPN 서비스가 트래픽을 처리하므로 데스크톱 시스템 프록시 절차를 그대로 적용할 수 없습니다. 앱별 프록시 목록에서 브라우저가 제외되지 않았는지 확인하고, 다른 VPN이 연결을 차지하고 있지 않은지도 살펴보세요.

브라우저 프록시 확장 프로그램을 잠시 끈 뒤 다시 시도하고, 이전 연결이 재사용되지 않도록 브라우저를 완전히 종료했다가 다시 실행하세요. Windows에서 netsh winhttp show proxy로 확인하는 것은 WinHTTP 프록시입니다. 모든 브라우저의 시스템 프록시 상태를 나타내지는 않으므로 유일한 판단 근거로 삼지 마세요.

4단계: 규칙 일치 여부와 실제 외부 연결 정책 확인

클라이언트에서 규칙 모드로 전환한 뒤 「연결」 또는 해당 요청 목록을 열고, 문제가 발생한 웹사이트에 다시 접속하세요. 대상 도메인, 일치한 규칙, 선택된 정책 그룹, 최종 노드를 기록합니다. Clash 규칙은 보통 순서대로 적용되므로 앞쪽의 범위가 넓은 규칙이 먼저 적용되어 뒤쪽의 도메인 규칙이 실행되지 않을 수 있습니다.

대상 요청이 연결 목록에 표시되는지 확인하세요. 기록이 없다면 앱이 프록시를 사용하지 않거나, 기존 연결을 재사용하거나, 다른 네트워크 도구가 트래픽을 처리하고 있을 가능성이 큽니다.
최종 연결이 DIRECT라면 해당 웹사이트에 직접 연결해야 하는지, 도메인 규칙에 로그인·이미지·API 도메인이 빠지지 않았는지 확인하세요.
최종 연결이 REJECT라면 차단 규칙이 잘못 적용되지 않았는지 확인하세요. 모든 규칙을 바로 삭제하지 마세요.
프록시 그룹을 통과한다면 그룹 내부의 선택 항목을 펼쳐 사용할 수 없는 노드나 DIRECT가 선택되지 않았는지 확인하세요.
잠시 글로벌 모드로 전환해 테스트한 노드를 직접 선택한 뒤 같은 주소에 접속하세요. 비교를 마친 다음에는 규칙 모드로 되돌리세요.

글로벌 모드에서는 열리지만 규칙 모드에서는 열리지 않는다면, 두 요청의 실제 외부 연결 경로가 어떻게 다른지 확인하세요. 글로벌 모드에서 열린다는 이유로 이를 영구적인 해결책으로 삼지는 마세요. 글로벌 모드는 많은 연결의 경로를 바꾸므로 로컬 서비스, 업무 네트워크, 계정 로그인에 영향을 줄 수 있습니다. 두 모드 모두 실패한다면 노드와 도메인 확인 경로를 다시 살펴보세요. 도메인 규칙을 반복해서 추가할 필요는 없습니다.

사용자 지정 규칙은 클라이언트에서 지원하는 덮어쓰기 또는 병합 기능으로 저장하세요. 구독이 생성한 파일을 직접 수정하면 다음 업데이트 때 변경 사항이 덮어써질 수 있습니다. 먼저 필요한 범위만 포함한 규칙을 적용하고, 페이지에 필요한 API 도메인도 확인하세요. 범위가 지나치게 넓은 도메인 접미사 규칙으로 무관한 트래픽까지 바꾸지 마세요.

5단계: DNS 오염, 도메인 확인 실패, 정상적인 Fake-IP 동작 구분

브라우저에 도메인 확인 실패가 표시된다고 해서 반드시 DNS 오염인 것은 아닙니다. 상위 DNS 시간 초과, 암호화 DNS 서버 접속 불가, 노드 도메인 확인 실패, 브라우저의 보안 DNS와 클라이언트의 확인 경로 차이도 비슷한 증상을 일으킬 수 있습니다. 먼저 로그에서 확인에 실패한 도메인이 대상 웹사이트인지 프록시 노드 자체의 도메인인지 살펴보세요.

먼저 현재 DNS 조회 경로 확인

Windows에서는 다음 명령으로 시스템 기본 DNS의 조회 결과를 확인할 수 있습니다. 이 결과는 해당 시스템 조회만 반영하며 브라우저, Clash 내장 DNS 또는 원격 프록시의 조회 결과를 자동으로 보여주지는 않습니다.

nslookup example.com
ipconfig /flushdns

두 번째 명령은 Windows DNS 클라이언트 캐시를 지우지만 브라우저 캐시나 커널 DNS 캐시는 함께 삭제하지 않습니다. DNS 설정을 변경한 뒤에는 클라이언트 기능에 따라 설정을 다시 불러오거나 커널을 재시작하고, 브라우저 연결도 새로 만들어야 합니다. 두 DNS 서버가 서로 다른 IP를 반환한다고 해서 바로 오염으로 판단하지 마세요. CDN이 접속 위치와 상태에 따라 서로 다른 결과를 반환하는 것은 정상일 수 있습니다.

Fake-IP가 가상 주소를 반환해도 도메인 확인 오류는 아닙니다

Fake-IP 모드를 사용하면 클라이언트가 설정에 따라 198.18.0.0/16 범위의 가상 주소를 반환할 수 있습니다. 이 주소는 도메인과 연결의 매핑을 유지하기 위한 것이며, 대상 웹사이트의 실제 서버 주소가 아닙니다. 이 주소가 보인다는 이유만으로 오류라고 판단하지 마세요. 해당 연결이 올바르게 처리되고 있는지, 커널에 대응하는 매핑이 남아 있는지 확인해야 합니다.

특정 앱에서만 문제가 발생한다면 자체 DNS를 사용하거나 이전 Fake-IP 주소를 캐시했는지, 프록시를 우회하는지 먼저 확인하세요.
로그에 상위 DNS 시간 초과가 표시된다면 nameserver에 설정된 서버에 현재 네트워크에서 접속할 수 있는지 확인하세요. 출처를 알 수 없는 DNS 주소를 한꺼번에 여러 개 추가하지 마세요.
노드 주소가 도메인이라면 ‘노드에 연결해야 DNS를 사용할 수 있지만, DNS를 확인해야 노드에 연결할 수 있는’ 순환 문제가 없는지 확인하세요. mihomo에서는 설정에 따라 proxy-server-nameserver로 노드 도메인 확인용 DNS를 지정할 수 있습니다. 이전 커널과의 호환성은 별도로 확인해야 합니다.
브라우저에서 보안 DNS를 사용 중이라면 잠시 끄고 비교 테스트를 해 보세요. 테스트가 끝나면 실제 필요에 맞게 다시 설정하고, 어떤 DNS 경로에서 차이가 발생했는지 기록하세요.

nameserver 또는 fallback을 변경하기 전에 기존 설정을 보관하세요. fallback의 활성화 여부와 결과 반영 방식은 커널 및 필터 설정에 따라 다르며, 단순히 ‘첫 번째 서버가 실패하면 두 번째 서버를 호출하는’ 기능이 아닙니다. DNS 문제가 발생하면 로그와 현재 커널 문서를 바탕으로 수정하세요. 출처가 불분명한 예시로 DNS 설정 전체를 교체하지 마세요.

6단계: TUN을 켰을 때만 실패한다면 라우팅 및 DNS 처리 확인

TUN을 끄고 명시적 프록시를 사용하면 정상인데 TUN을 켰을 때 실패한다면 문제 범위는 가상 네트워크 어댑터, 권한, 라우팅, DNS 처리 또는 다른 VPN과의 충돌로 좁혀집니다. TUN이 처리하는 연결은 라우팅, 제외 설정, 플랫폼 구현에 따라 달라집니다. TUN을 켰다고 모든 앱이 반드시 프록시를 통과하는 것은 아닙니다.

클라이언트에 현재 플랫폼에서 필요한 서비스 또는 네트워크 권한이 부여되었는지 확인하고, 시작 로그에 장치 생성이나 라우트 추가 실패가 기록되어 있는지 살펴보세요.
다른 VPN, 네트워크 가속기, 중복 실행 중인 Clash 클라이언트를 일시 중지하세요. 업무용 기기의 보안 소프트웨어와 기업 VPN은 먼저 관리 정책에 따라 처리해야 합니다.
사용자 지정 라우팅 제외 또는 앱별 우회 설정을 확인하고, 문제가 발생한 앱과 대상 주소가 제외 대상에 포함되지 않았는지 살펴보세요.
dns-hijack 설정이 현재 커널 구성과 일치하는지 확인하세요. 일반 DNS 포트의 요청을 가로채더라도 앱 자체의 HTTPS DNS 요청을 복호화할 수는 없습니다.
단순하고 동작을 설명할 수 있는 단일 트래픽 처리 방식으로 되돌린 뒤 다시 테스트하세요. 문제가 발생한 상태에서 시스템 프록시, 여러 VPN, 복잡한 라우팅 덮어쓰기를 동시에 켜지 마세요.

작은 페이지는 정상인데 큰 페이지나 다운로드만 멈춘다면 노드와 사이트 문제를 배제한 뒤 MTU 또는 경로 문제를 살펴볼 수 있습니다. MTU 변경을 첫 번째 조치로 삼지 마세요. 먼저 현재 값을 저장하고, 한 번에 하나의 값만 변경해 같은 요청을 비교한 뒤 개선이 없으면 원래대로 되돌리세요.

점검 결과 정리: 최소한의 근거로 문제 위치 찾기

위 단계를 마치면 설정이 유효하지 않은지, 로컬 포트가 수신 중이 아닌지, 앱이 시스템 프록시를 우회하는지, 규칙이 잘못 적용되는지, 노드 또는 도메인 확인 경로에 문제가 있는지 구분할 수 있습니다. 그래도 지원이 필요하다면 ‘연결됨으로 표시되는데 열리지 않는다’는 스크린샷만 보내기보다 아래 정보를 함께 제공하면 원인을 파악하는 데 도움이 됩니다.

운영체제, 클라이언트 이름과 정확한 버전, 커널 이름과 버전. 클라이언트의 「정보」 페이지나 시작 로그에서 확인할 수 있습니다.
실제 수신 포트, 시스템 프록시 및 TUN 상태, 특정 브라우저에서만 문제가 발생하는지 여부.
같은 URL을 명시적 프록시, 규칙 모드, 글로벌 모드에서 테스트한 결과와 각 테스트의 정확한 시간.
실패한 요청에 적용된 규칙, 정책 그룹, 관련 로그 오류. 계정, 구독 토큰, 민감한 주소는 가리고 공유하세요.

마지막으로 임시 변경한 프록시 모드, 브라우저 보안 DNS, 로그 수준을 원래대로 되돌리고 정상 작동을 확인한 변경 사항만 유지하세요. 클라이언트를 다시 설치해야 한다면 로컬 덮어쓰기 설정과 규칙을 먼저 백업하세요. 재설치만으로는 구독 만료, 노드 장애, 웹사이트의 접속 거부가 해결되지 않습니다.