Clash 연결은 됐는데 웹페이지가 열리지 않을 때: 시스템 프록시·포트 충돌·규칙 점검

먼저 ‘클라이언트 실행’과 ‘요청의 프록시 통과’를 구분하세요

먼저 클라이언트의 ‘연결’과 ‘로그’ 화면을 열고, 열리지 않는 웹페이지를 새로고침하세요. 창에 ‘실행 중’이라고 표시되거나 시스템 트레이 아이콘이 켜져 있거나 노드에 지연 시간이 표시되는 것만으로는 일부 단계가 정상이라는 뜻일 뿐입니다. 브라우저의 해당 요청이 실제로 프록시를 거쳤거나 대상 사이트에 접속할 수 있다는 의미는 아닙니다.

Clash는 프록시 코어와 클라이언트를 통칭할 때 흔히 쓰는 이름이며, Clash Meta는 이후 mihomo라는 이름으로 계속 개발되고 있습니다. 그래픽 클라이언트마다 설정 스위치의 위치는 조금씩 다릅니다. 아래 내용은 Windows 11의 시스템 설정 경로, 일반적인 클라이언트의 ‘시스템 프록시’, ‘프록시 모드’, ‘연결’, ‘로그’ 기능과 mihomo 설정 항목을 기준으로 설명합니다. 포트 예시는 모두 7890을 사용하며, 실제 설정은 현재 구성에 맞춰야 합니다.

현재 상태 기록: 클라이언트 이름, 코어 버전, 활성 설정 이름, 현재 노드, 혼합 포트, TUN 활성화 여부를 기록합니다.
기본 네트워크 연결 확인: 시스템 프록시와 TUN을 끈 뒤 평소 직접 접속되는 웹사이트를 열어 봅니다. 그래도 접속되지 않으면 Wi-Fi, 게이트웨이, 인터넷 인증 또는 학교 네트워크 로그인을 먼저 확인하세요.
테스트 범위 좁히기: 클라이언트 하나만 실행하고 같은 URL로 반복 테스트합니다. 한 번에 설정 하나만 변경하세요.
요청 확인: 새로고침 후 연결 기록이 없다면 먼저 트래픽 진입 경로를 확인하세요. 기록은 있지만 연결에 실패한다면 아웃바운드 노드, 규칙, DNS를 점검합니다.

시스템 프록시 확인: 브라우저 요청이 로컬 포트에 도달하는지

주소·포트·프록시 예외 설정 확인

Windows 11에서 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’ → ‘수동 프록시 설정’ → ‘편집’을 엽니다. 일반 브라우저의 HTTP 프록시 서버 주소는 클라이언트의 수신 주소와 일치해야 합니다. 클라이언트가 로컬 연결만 수신한다면 보통 127.0.0.1을 입력하고, 포트에는 실제 HTTP 포트나 혼합 포트를 입력합니다. 예: 7890. 제어판의 API 포트를 프록시 포트로 입력하지 마세요.

macOS에서 ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 서비스 → ‘세부사항’ → ‘프록시’를 열어 웹 프록시와 보안 웹 프록시를 확인합니다. 시스템 버전에 따라 항목 이름이 조금씩 다를 수 있습니다. 자동 프록시 구성을 사용한다면 PAC 주소에 접속할 수 있는지, 스크립트 규칙이 대상 도메인을 직접 연결하도록 하는지도 확인하세요. 프록시 예외 목록에서 대상 도메인이 실수로 제외되지 않았는지도 살펴봅니다.

클라이언트를 다시 시작한 뒤 시스템 설정을 확인하세요. 이전 프로세스가 종료되면서 다른 프록시 설정값으로 복원됐을 수 있습니다.
Firefox에서는 ‘설정’ → ‘일반’ → ‘네트워크 설정’ → ‘설정’에서 ‘시스템 프록시 설정 사용’을 선택하거나 프록시를 직접 입력할 수 있습니다.
시스템 프록시 설정을 덮어쓰지 않도록 브라우저 프록시 확장 기능을 잠시 끄세요. 회사에서 관리하는 브라우저는 정책의 영향을 받을 수도 있습니다.
시스템 프록시는 모든 앱의 트래픽을 처리하지 않습니다. 터미널 도구, 게임, 일부 스토어 앱은 앱별로 설정해야 할 수 있습니다. 일반 프록시가 정상임을 확인한 뒤 TUN을 사용할 수도 있습니다.

브라우저 설정을 거치지 않고 프록시를 지정해 요청하기

Windows PowerShell에서는 이전 버전 PowerShell의 curl 별칭과 혼동하지 않도록 curl.exe를 사용하세요. 아래 명령은 로컬 HTTP 프록시로 요청을 한 번 보내며, 전체 제한 시간은 15초입니다. example.com은 연결 테스트용 주소일 뿐이므로 실제로 접속되지 않는 사이트로 바꿔 다시 테스트하세요.

curl.exe -v --connect-timeout 5 --max-time 15 --proxy http://127.0.0.1:7890 https://example.com/ -o NUL

macOS와 Linux에서는 해당 명령을 실행하세요:

curl -v --connect-timeout 5 --max-time 15 --proxy http://127.0.0.1:7890 https://example.com/ -o /dev/null

명령으로 HTTP 응답을 받을 수 있지만 브라우저에서만 실패한다면 브라우저 확장 기능, 별도 프록시 설정, 캐시된 연결을 확인하세요. 127.0.0.1:7890 연결이 거부된다면 먼저 로컬 포트가 수신 중인지 확인하세요. 바로 구독을 바꾸지 마세요. 403 응답도 네트워크 시간 초과와 구분해야 합니다. HTTP 서비스가 응답했지만 대상 사이트나 중간 장비가 요청을 거부했을 수 있습니다.

포트 충돌 확인: 현재 코어가 포트를 수신하는지 점검

mixed-port는 HTTP와 SOCKS 혼합 프록시 진입점을 제공하고, external-controller는 제어 API에 사용됩니다. 두 항목의 용도는 다릅니다. 설정 예시의 9090을 브라우저 프록시 입력란에 그대로 넣으면 안 됩니다. 아래 설정 조각은 항목 확인용일 뿐이며, 전체 구독 설정을 덮어쓰지 마세요:

mixed-port: 7890
allow-lan: false
mode: rule
external-controller: 127.0.0.1:9090

Windows PowerShell에서 포트를 수신 중인 프로세스를 확인합니다:

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

출력에 표시된 OwningProcess 번호를 Get-Process -Id에 입력해 프로세스 이름을 확인합니다. macOS에서는 첫 번째 명령을, Linux에서는 두 번째 명령을 사용할 수 있습니다. 일부 프로세스 정보는 적절한 권한이 있어야 표시됩니다.

lsof -nP -iTCP:7890 -sTCP:LISTEN
ss -ltnp 'sport = :7890'

확인 결과	가능한 원인	다음 단계
수신 기록 없음	코어가 시작되지 않았거나 설정을 불러오지 못했거나 실제 포트가 7890이 아님	시작 로그와 활성 설정을 확인해 실제 수신 포트를 파악합니다
다른 앱이 포트를 사용 중	이전 클라이언트, 다른 프록시 도구 또는 백그라운드 서비스가 실행 중	충돌하는 앱을 정상 종료한 뒤 현재 코어를 다시 시작합니다
로그에 address already in use 표시	현재 코어가 주소에 바인딩하지 못함	포트를 비우거나 포트를 변경한 뒤 시스템 프록시도 함께 수정합니다
::1에서만 수신 중	수신 주소와 입력한 IPv4 루프백 주소가 일치하지 않음	수신 설정을 확인하고 프록시 주소를 수신 주소와 일치시킵니다

포트 번호만 보고 정체를 알 수 없는 프로세스를 강제 종료하지 마세요. 먼저 프로세스 이름과 출처를 확인하세요. 혼합 포트를 7891로 변경했다면 시스템 프록시, 브라우저의 별도 프록시 설정, 터미널 환경 변수도 함께 수정해야 합니다. 그렇지 않으면 요청이 계속 이전 포트로 전송됩니다.

노드 확인: 지연 시간 표시만으로 대상 사이트 접속 여부를 알 수 없습니다

‘프록시’ 화면에서 실제 아웃바운드에 사용되는 정책 그룹을 찾으세요. 정책 그룹은 다른 그룹을 가리킬 수도 있고 DIRECT가 선택되어 있을 수도 있습니다. 화면에서 특정 노드가 강조 표시되어도 현재 연결이 반드시 그 노드를 사용한다는 뜻은 아닙니다. ‘연결’ 세부정보로 돌아가 요청 도메인, 정책 경로, 최종 아웃바운드 노드를 확인하세요.

같은 정책 그룹에서 다른 노드를 직접 선택하고 기존 연결을 닫은 뒤 대상 웹페이지를 다시 불러옵니다.
잠시 전역 모드로 바꾸고 전역 정책 그룹에서 프록시 노드를 직접 선택한 뒤 같은 요청을 테스트합니다.
전역 모드에서는 접속되지만 규칙 모드에서 실패한다면 규칙 매칭을 확인하세요. 두 모드 모두 실패한다면 노드와 로컬 네트워크를 먼저 점검합니다.
서비스 제공업체 계정 페이지에서 구독 만료 여부, 데이터 사용량 소진 여부, 노드 점검 공지를 확인하세요.

전역 모드는 코어에 들어온 트래픽의 라우팅 선택만 바꿉니다. 모든 앱의 트래픽을 자동으로 코어에 전달하지는 않습니다. 테스트 후에는 규칙 모드로 되돌리세요. 노드 지연 시간은 보통 클라이언트에 설정된 테스트 URL을 기준으로 측정됩니다. 해당 테스트 요청이 그 시점에 완료됐다는 뜻일 뿐, 150 ms라는 숫자만으로 동영상 재생, 로그인 또는 특정 웹사이트 접속이 정상이라고 판단할 수는 없습니다.

잘못된 규칙 매칭 확인: 처음 일치한 규칙 살펴보기

규칙 모드는 위에서부터 차례로 매칭하며, 처음 일치한 규칙이 연결 경로를 결정합니다. 대상 도메인이 직접 연결 규칙에 포함됐거나, 범위가 넓은 규칙이 앞에 있거나, 규칙이 가리키는 정책 그룹에서 사용할 수 없는 노드를 선택한 것이 흔한 원인입니다. 설정 맨 아래의 MATCH만 읽지 말고 해당 연결의 세부정보에 기록된 규칙을 기준으로 확인하세요.

아래 예시에서는 규칙 순서가 미치는 영향을 보여 줍니다. 여기서 DIRECT와 REJECT는 내장 정책입니다. 이 조각은 전체 설정이 아니므로 사용 중인 구독에 그대로 추가하지 마세요:

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,REJECT

이 설정 조각에서는 example.com과 그 하위 도메인이 먼저 직접 연결 규칙에 매칭되고, 그 밖의 요청은 거부됩니다. 두 줄의 순서를 바꾸면 앞쪽의 MATCH가 모든 요청을 처리해 뒤에 있는 도메인 규칙은 적용되지 않습니다. ‘규칙을 작성했는데 작동하지 않는’ 대표적인 원인입니다.

DIRECT에 매칭된 뒤 접속 실패: 대상 사이트가 직접 연결에 적합한지 먼저 확인하세요. 프록시가 필요하다면 더 구체적인 도메인 규칙을 관련된 광범위 규칙보다 앞에 배치합니다.
REJECT에 매칭됨: 광고 필터나 사용자 지정 차단 규칙이 로그인, 인증 코드 또는 정적 리소스 도메인을 잘못 차단하는지 확인하세요.
프록시 그룹에 매칭됐지만 접속 실패: 그룹 이름만 보고 판단하지 말고 그룹에서 최종 선택된 노드를 확인하세요.
설정 업데이트 후 문제가 다시 발생: 구독 갱신 시 덮어쓰이지 않도록 클라이언트의 덮어쓰기 또는 병합 기능으로 사용자 지정 규칙을 저장하세요.

규칙을 수정한 뒤 해당 기존 연결을 닫고 다시 테스트하세요. 브라우저가 이미 연결된 HTTP/2 연결을 재사용할 수 있어 새로고침만으로는 라우팅 규칙이 다시 적용되지 않을 수 있습니다. 한 페이지에서도 여러 리소스 도메인에 요청할 수 있습니다. 메인 페이지는 열리지만 이미지나 로그인에 문제가 있다면 실패한 리소스의 연결 기록을 확인하세요.

DNS와 TUN 확인: 이름 조회 문제와 트래픽 가로채기 문제를 구분하기

먼저 DNS 오류인지 확인

Could not resolve host, no such host 또는 로그의 DNS 시간 초과가 발생하면 도메인을 어떤 구성 요소가 조회하는지 먼저 확인하세요. 브라우저 보안 DNS, 시스템 DNS, mihomo의 DNS 모듈은 서로 다른 경로를 사용할 수 있습니다. Windows의 nslookup example.com은 기본적으로 시스템에서 선택한 DNS의 응답을 테스트하며, mihomo 내부의 DNS가 정상이라는 뜻은 아닙니다. 실제 요청 로그와 함께 판단해야 합니다.

fake-ip를 사용 중이라면 198.18.0.0/15 범위의 주소가 보여도 반드시 오류는 아닙니다. 코어가 도메인에 할당하는 매핑 주소일 수 있으며, 프록시가 트래픽을 처리해야 원래 도메인 정보로 복원됩니다. TUN을 끈 뒤에도 브라우저에 이런 주소가 캐시되어 있으면 접속이 계속 실패할 수 있습니다. DNS와 트래픽 경로를 먼저 일치시킨 다음 브라우저를 다시 시작하세요. 필요하면 Windows에서 ipconfig /flushdns를 실행해 시스템 캐시를 지울 수 있습니다.

nameserver와 fallback을 무작위로 수집한 공용 주소로 전부 바꾸지 마세요. 먼저 현재 네트워크에서 상위 DNS 주소와 전송 방식에 연결할 수 있는지 확인하세요. 상위 DNS에 도메인 이름을 사용하는 경우 시작 단계에서 이름을 조회하는 경로도 고려해야 합니다. 브라우저 보안 DNS는 비교를 위해 잠시 끌 수 있으며, 원인을 확인한 뒤 실제 필요에 맞게 다시 설정하세요.

일반 프록시가 정상인지 확인한 다음 TUN을 따로 테스트

TUN은 가상 네트워크 인터페이스로 트래픽을 가로채므로 시스템 프록시보다 더 많은 구성 요소가 관여합니다. 프록시를 명시한 명령은 성공하지만 TUN을 켠 뒤 전체 네트워크가 실패한다면 노드를 계속 바꾸지 말고 클라이언트 서비스 권한, 가상 인터페이스, 라우팅, DNS 하이재킹을 확인하세요.

라우팅 충돌을 배제하려면 다른 VPN, 가상 네트워크, 프록시 클라이언트를 끄고 현재 도구만 남기세요.
클라이언트가 요구하는 서비스 모드나 권한이 올바르게 활성화됐는지 확인하고 TUN 시작 로그에 오류가 있는지 살펴보세요.
먼저 TUN을 끄고 시스템 프록시만 테스트합니다. 그런 다음 TUN을 켜고 클라이언트 권장 방식에 따라 시스템 프록시를 설정해 경로가 중복되면서 판단이 어려워지지 않게 하세요.
route print(Windows) 또는 ip route(Linux)로 전환 전후의 라우팅을 확인하세요. 회사 네트워크에서 유지해야 하는 내부망 경로는 별도로 처리해야 합니다.

mihomo의 TUN 설정에서 dns-hijack을 사용해 해당 DNS 요청을 가로챌 수 있지만, 일반적인 53번 포트 하이재킹만으로 모든 암호화 DNS를 처리할 수 있는 것은 아닙니다. 브라우저의 DoH는 HTTPS 트래픽이므로 실제 규칙과 DNS 구성에 맞게 처리해야 합니다.

오류별 마무리: 재현 가능한 최소 사례 기록

증상 또는 로그	우선 점검 항목
로컬 포트 7890 연결 거부	포트, 수신 주소, 코어 실행 상태
요청이 코어에 들어갔지만 아웃바운드 연결 시간 초과	최종 노드, 상위 네트워크 연결, 아웃바운드 차단 여부
전역 모드에서는 성공하지만 규칙 모드에서는 실패	규칙 매칭, 정책 그룹 선택, 직접 연결 경로
TUN을 켰을 때만 실패	서비스 권한, 가상 인터페이스, 라우팅, DNS 하이재킹
certificate verify failed	시스템 시간, 인증서 체인, HTTPS 검사 장비
특정 사이트 하나에서만 403 또는 429 응답	대상 사이트의 제한, 출구 IP 주소, 계정, 요청 빈도

인증서 오류가 발생하면 먼저 시스템 날짜와 시간을 동기화하고, 네트워크 인증이 필요한지, 회사 네트워크에 HTTPS 검사 장비가 설치되어 있는지 확인하세요. 인증서 검증을 건너뛰는 방법을 일반적인 해결책으로 사용하지 마세요. 403 또는 429가 발생해도 반복해서 새로고침하지 마세요. 프록시 연결은 이미 성립했고 사이트의 접근 정책이나 요청 빈도 제한이 실패 원인일 수 있습니다.

추가 지원을 요청할 때는 클라이언트와 코어 버전, 시스템 버전, 재현 시간, 대상 도메인, 시스템 프록시 및 TUN 상태, 프록시를 명시한 테스트 결과, 같은 시간대의 오류 로그를 제공하세요. ‘브라우저가 열리지 않음’보다 ‘로컬 포트 연결 가능, 규칙은 특정 정책 그룹에 매칭되지만 최종 노드의 아웃바운드 연결이 시간 초과됨’이라고 설명하면 해결 방향을 훨씬 명확하게 파악할 수 있습니다.