1. 연결 상태와 실제 요청 경로 구분하기
클라이언트에 ‘실행 중’ 또는 ‘연결됨’이라고 표시되는 것은 대개 코어가 실행 중이거나 시스템 VPN 인터페이스가 만들어졌다는 뜻입니다. 노드 지연 시간 테스트에 성공해도 테스트 대상 주소에 그 시점에 접속할 수 있었다는 의미일 뿐입니다. 브라우저 요청은 프록시 진입점, 규칙 매칭, 프록시 그룹 선택, 노드 연결, 도메인 조회를 차례로 거칩니다. 이 중 한 단계라도 실패하면 웹페이지가 열리지 않을 수 있습니다.
먼저 현재 설정을 저장하고 클라이언트 이름과 버전, 코어 이름과 버전을 기록하세요. Clash는 설정 생태계에서 널리 쓰이는 명칭이며, Clash Meta는 이후 mihomo라는 이름을 사용합니다. 클라이언트마다 포함된 코어와 메뉴 구성이 다르므로 특정 화면의 스위치가 모든 버전에 있다고 가정하면 안 됩니다.
먼저 기본 항목 세 가지 확인하기
- 시스템 프록시와 TUN을 잠시 끄고 평소 직접 접속하는 웹사이트를 열어 보세요. 이때도 접속할 수 없다면 프록시 규칙을 바로 수정하지 말고 Wi-Fi, 게이트웨이, 인증 페이지, 시스템 네트워크부터 확인하세요.
- 기존 설정을 복원한 뒤 같은 URL로 브라우저와 명령줄을 각각 테스트하세요. 같은 대상을 기준으로 비교해야 웹사이트별 접속 차이를 클라이언트 문제로 오인하지 않습니다.
- 클라이언트의 ‘로그’와 ‘연결’ 화면을 열고 테스트 시간, 대상 도메인, 매칭된 규칙, 사용한 프록시 그룹, 오류 원문을 기록하세요. 로그를 공유하기 전에는 구독 URL, 비밀번호, 토큰, 노드 인증 정보를 가리세요.
2. 시스템 프록시와 로컬 수신 포트 확인하기
시스템 프록시는 해당 설정을 사용하는 앱에만 적용되며 모든 프로그램의 연결을 가로채지는 않습니다. 브라우저 확장 프로그램, Firefox의 별도 프록시 설정, 터미널 환경 변수 등이 시스템 설정을 덮어쓸 수 있습니다. 아래에서는 HTTP 또는 mixed 진입점의 예시로 127.0.0.1:7890을 사용합니다. 먼저 현재 실행 중인 설정에서 실제 포트를 확인하세요. 모든 클라이언트가 7890을 사용하는 것은 아닙니다.
플랫폼별 프록시 진입점 확인
- Windows 11: ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’ → ‘수동 프록시 설정’을 엽니다. 수동 프록시를 사용한다면 주소와 포트가 클라이언트 설정과 일치하는지 확인하세요. 자동 구성 스크립트를 사용한다면 스크립트 주소를 확인하고, 출처를 알 수 없는 이전 스크립트는 함께 남겨 두지 마세요.
- macOS: ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 서비스 → ‘세부사항’ → ‘프록시’를 엽니다. 웹 프록시, 보안 웹 프록시, 자동 프록시 구성을 확인하세요. Wi-Fi와 유선 네트워크를 전환했다면 현재 서비스에 설정이 적용되어 있는지도 확인해야 합니다.
- Android: 대부분의 Clash 계열 클라이언트는 시스템 VPN 서비스로 트래픽을 처리합니다. VPN 권한과 앱 분할 목록을 확인하고, 다른 VPN이 유일한 활성 VPN 연결을 차지하고 있지는 않은지 살펴보세요. 데스크톱의 수동 프록시 설정 절차를 그대로 적용하면 안 됩니다.
프록시를 명시해 비교 테스트하기
# Windows PowerShell에서는 curl.exe 사용; macOS/Linux에서는 curl 사용
curl.exe -I --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/
curl.exe -I --connect-timeout 10 --max-time 20 --noproxy "*" https://example.com/첫 번째 명령은 로컬 프록시를 명시적으로 거치고, 두 번째 명령은 환경 프록시를 무시하고 직접 연결을 시도합니다. 도메인은 예시일 뿐이므로 문제를 확인 중인 웹사이트 주소로 바꾸세요. 첫 번째 명령은 성공하지만 브라우저는 실패한다면 브라우저의 프록시 설정 출처와 확장 프로그램을 확인하세요. Failed to connect to 127.0.0.1 오류가 나면 원격 노드를 조정하기 전에 로컬 수신 상태부터 확인해야 합니다.
HTTPS 요청이 HTTP 프록시를 통과할 때 출력되는 200 Connection established는 CONNECT 터널이 만들어졌다는 뜻일 뿐입니다. 이후 대상 사이트의 HTTP 응답까지 확인해야 합니다. 대상 사이트가 403 또는 405를 반환하면 서버 응답을 받은 것이지만 페이지에 정상적으로 접속할 수 있다는 의미는 아닙니다. 일부 사이트는 HEAD 요청을 허용하지 않으므로 -I를 빼고 다시 테스트하세요.
3. 포트 충돌과 이전 프로세스 점유 여부 확인하기
클라이언트 창이 열렸다고 해서 코어가 포트를 정상적으로 열었다는 뜻은 아닙니다. 클라이언트 두 개를 동시에 실행하면 address already in use 또는 bind 오류가 흔히 발생합니다. 시스템 프록시가 여전히 7890을 가리키더라도 해당 포트를 점유한 것은 이전 클라이언트일 수 있으며, 유효한 설정을 잃은 백그라운드 서비스일 수도 있습니다.
# Windows PowerShell: 수신 프로세스 확인
Get-NetTCPConnection -State Listen -LocalPort 7890 |
Select-Object LocalAddress, LocalPort, OwningProcess
# macOS: 수신 프로세스 확인
lsof -nP -iTCP:7890 -sTCP:LISTEN
# Linux: 수신 프로세스 확인
ss -ltnp 'sport = :7890'- 수신 프로세스에 해당하는 프로그램을 확인하고 현재 클라이언트의 프로세스인지 살펴보세요. Windows에서는 작업 관리자의 ‘세부 정보’ 탭에서 PID로 찾을 수 있습니다.
- 사용하지 않는 클라이언트와 백그라운드 서비스를 정상적으로 종료한 다음 대상 클라이언트를 다시 시작하세요. 포트 번호만 보고 시스템 프로세스를 무작정 종료하지 마세요.
- 7892와 같은 다른 빈 포트로 변경했다면 시스템 프록시와 테스트 명령도 함께 수정해야 합니다. 변경 후 실제 수신 상태를 다시 확인하세요.
port는 일반적으로 HTTP 프록시 진입점을 제공하고, socks-port는 SOCKS 진입점을 제공합니다. mixed-port는 HTTP와 SOCKS 연결을 모두 받을 수 있습니다. SOCKS 전용 포트에 HTTP 요청을 보내면 실패할 수 있습니다. external-controller는 제어 인터페이스이지 웹 프록시 진입점이 아닙니다. 해당 포트를 시스템 프록시에 입력하지 마세요.
4. 프록시 그룹 선택과 규칙 매칭 확인하기
구독을 성공적으로 가져왔다는 것은 설정을 불러올 수 있다는 뜻일 뿐입니다. 규칙에서 참조하는 프록시 그룹이 여전히 DIRECT, 작동하지 않는 노드 또는 다른 중첩 프록시 그룹을 선택하고 있을 수 있습니다. 연결 세부 정보에서 이번 요청의 대상 도메인을 찾아 프록시 체인을 따라 최종 출구를 확인하세요. 홈 화면에 표시된 노드 이름만 확인해서는 안 됩니다.
모드를 전환해 원인 범위 좁히기
- 규칙 모드에서 대상에 접속해 매칭된 규칙과 정책을 기록하세요. 규칙은 일반적으로 순서대로 적용되므로 앞쪽의 포괄적인 규칙이 요청을 먼저 처리할 수 있습니다.
- 잠시 전역 모드로 전환하고 GLOBAL 그룹에서 테스트할 노드를 실제로 선택했는지 확인하세요. 전역 모드에서도 DIRECT가 선택될 수 있으므로 모드 이름만 확인해서는 안 됩니다.
- 웹페이지를 새로고침하고 새 연결을 확인하세요. 전역 모드에서는 성공하지만 규칙 모드에서는 실패한다면 규칙 순서, 규칙 세트 로드 여부, 관련 정책 그룹의 선택을 중점적으로 확인하세요.
- 테스트가 끝나면 규칙 모드로 되돌리세요. 전역 모드는 문제를 좁히기 위한 도구일 뿐, DNS 문제나 노드 오류, 로컬 포트 문제를 자동으로 해결하지 않습니다.
# 규칙 순서 예시: 설명용이며 전체 구독 설정을 덮어쓰지 마세요
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- MATCH,PROXY이 예시에서는 example.com과 하위 도메인이 먼저 직접 연결 규칙에 매칭되고, 마지막 규칙에서 나머지 요청을 PROXY로 전달합니다. PROXY는 설정에 이미 존재하는 프록시 또는 프록시 그룹이어야 합니다. 대상에 프록시 접속이 필요한데 앞선 직접 연결 규칙에 매칭되면 ‘다른 사이트는 되는데 특정 사이트만 열리지 않는’ 문제가 생길 수 있습니다.
노드를 변경한 뒤에는 테스트 연결을 새로 만들어야 합니다. 브라우저가 연결을 재사용하면 이전 경로가 계속 사용될 수 있으므로 필요한 경우 해당 활성 연결만 종료한 다음 다시 시도하세요. 노드 지연 시간이 표시된다고 해서 대상 사이트에 접속할 수 있거나 해당 노드가 현재 요청에 필요한 UDP 전송을 지원한다는 뜻은 아닙니다.
5. 오류 유형별로 DNS와 조회 경로 확인하기
DNS 문제의 대표적인 단서는 no such host, lookup failed, 조회 시간 초과입니다. 다만 i/o timeout은 노드에 연결하거나 대상에 접속하는 단계에서도 발생할 수 있으므로 로그의 대상 주소를 함께 확인해야 합니다. 먼저 노드 서버 도메인 조회가 실패한 것인지, 웹사이트 도메인 조회가 실패한 것인지 구분하세요. 각각 확인해야 할 위치가 다릅니다.
| 증상 | 우선 확인할 항목 | 확인 방법 |
|---|---|---|
| 노드 도메인을 조회할 수 없음 | 노드 도메인 조회기와 시작 시 조회 경로 | 노드 연결 전의 조회 로그 확인 |
| 시스템 조회 시간 초과 | 시스템 DNS, 게이트웨이 DNS, 수신 주소 | 지정한 DNS 서버에 조회 요청 |
| 브라우저는 실패하고 명령줄은 성공 | 브라우저 보안 DNS, 별도 프록시, 확장 프로그램 | 일시적으로 DNS와 프록시 설정 통일 |
| IPv6 대상에서만 시간 초과 | IPv6 경로와 출구 연결 상태 | IPv4와 IPv6 경로를 각각 테스트 |
시스템 DNS와 코어 DNS 구분하기
# 시스템 기본 DNS 서버 조회
nslookup example.com
# 코어가 실제로 127.0.0.1:1053에서 수신 중인 경우에만 사용
# dig가 시스템에 설치된 경우에만 사용
dig @127.0.0.1 -p 1053 example.com Anslookup이 성공해도 코어의 DNS가 정상이라는 뜻은 아닙니다. 두 경로가 서로 다른 상위 DNS 서버를 사용할 수 있습니다. 반대로 조회가 실패했다고 해서 프록시를 통한 조회 요청도 반드시 실패하는 것은 아닙니다. HTTP CONNECT로 도메인에 접속하는 경우와 앱이 로컬에서 먼저 주소를 조회한 뒤 연결하는 경우는 조회 경로가 다를 수 있습니다.
mihomo의 DNS 설정에서 nameserver, nameserver-policy, proxy-server-nameserver 등의 항목은 서로 다른 상황에 영향을 주므로 코어 버전별 지원 여부를 확인해야 합니다. 규칙으로 DNS 상위 서버 연결을 선택하도록 설정했다면 ‘DNS 서버에 접속하려면 노드가 필요하고, 노드에 연결하려면 DNS가 필요한’ 순환 의존성이 생기지 않는지도 확인하세요. 다른 구독의 DNS 설정 블록 전체를 그대로 붙여 넣지 마세요.
Fake-IP와 브라우저 보안 DNS
Fake-IP 모드가 반환하는 가상 주소는 이후 매핑에 사용되는 값이며 대상 웹사이트의 실제 주소가 아닙니다. 흔히 198.18.0.0/16 대역을 사용하므로 이 주소가 보인다는 사실만으로 DNS 변조를 의심할 필요는 없습니다. 이후 연결이 주소 매핑을 담당하는 동일한 코어로 들어가는지 확인하세요. 실제 IP가 필요한 앱에서 호환성 문제가 분명하게 확인된 경우에만 fake-ip-filter에 해당 항목을 추가하는 방안을 검토하세요.
브라우저에서 보안 DNS를 켜면 예상한 시스템 조회 경로를 우회할 수 있습니다. 해당 설정을 잠시 끄고 비교 테스트한 뒤 필요한 설정을 복원하세요. DNS를 변경한 후 Windows에서는 ipconfig /flushdns를 실행해 시스템 캐시를 지울 수 있습니다. 브라우저와 코어에 자체 캐시가 남아 있을 수 있으므로 각각 다시 테스트해야 합니다. 보안 기능을 계속 꺼 두는 것을 일반적인 해결책으로 삼지 마세요.
6. TUN에서만 실패한다면 경로와 권한 확인하기
TUN을 끄고 HTTP 프록시를 명시하면 접속되지만 TUN을 켠 상태에서 실패한다면 가상 네트워크 어댑터, 시스템 경로, DNS 가로채기, 다른 VPN을 먼저 확인하세요. TUN은 가상 네트워크 인터페이스와 경로를 통해 트래픽을 전달합니다. 실제로 처리되는 범위는 경로와 제외 설정에 따라 다르므로 모든 앱과 프로토콜이 자동으로 정상 작동하는 것은 아닙니다.
- 권한: 데스크톱 클라이언트는 인터페이스를 만들고 경로를 변경하기 위해 관리자 권한이나 보조 서비스가 필요한 경우가 많습니다. 스위치를 반복해서 누르기보다 관련 서비스가 실행 중인지 확인하세요.
- 경로: Windows에서는
route print, macOS에서는netstat -rn, Linux에서는ip route로 경로를 확인하세요. 먼저 출력을 저장하고 기본 경로를 바로 삭제하지 마세요. - 인터페이스 선택: 유선, Wi-Fi, 가상 머신 네트워크 어댑터를 동시에 연결하면 자동으로 선택된 출구가 예상과 다를 수 있습니다. 테스트 환경에서는 실제로 인터넷에 연결된 인터페이스 하나만 남겨 확인하세요.
- VPN 충돌: 회사 VPN, 다른 프록시, 가상 네트워크 도구가 경로를 변경할 수 있습니다. 허용되는 경우 하나씩 종료하며 비교 테스트하세요. 회사 기기에서는 관리 정책을 따라야 합니다.
- 프로토콜과 MTU: 작은 요청은 성공하지만 큰 페이지나 다운로드가 멈춘다면 UDP, 경로 MTU, 패킷 분할 문제를 확인하세요. 근거 없이 stack이나 MTU 값을 임의로 바꾸지 마세요.
7. 테스트 결과로 원인을 좁히고 설정 복원하기
위 항목을 확인한 뒤 문제를 명확한 유형으로 분류하세요. 유용한 점검 기록에는 ‘어떤 진입점에서, 어떤 대상을, 어떤 모드로 테스트했고, 어떤 오류가 발생했는지’가 담겨야 합니다. 그저 ‘아직도 연결이 안 됨’이라고만 기록해서는 원인을 찾기 어렵습니다. 아래 표를 마지막 점검에 활용하세요.
| 테스트 결과 | 후속 조치 |
|---|---|
| 프록시 직접 지정 시 성공, 브라우저에서는 실패 | 시스템 프록시, 브라우저 확장 프로그램, 별도 프록시 설정 확인 |
| 로컬 프록시 포트에 연결할 수 없음 | 코어 시작 로그, 수신 포트, 포트를 점유한 프로세스 확인 |
| 전역 모드에서는 성공, 규칙 모드에서는 실패 | 매칭된 규칙, 규칙 세트 로드 상태, 최종 프록시 그룹 확인 |
| 여러 노드에서 모두 도메인 조회 오류 발생 | 노드 도메인과 대상 도메인의 DNS 경로 구분 |
| 시스템 프록시는 정상이고 TUN에서만 실패 | 권한, 경로, DNS 가로채기, VPN 충돌 확인 |
| 특정 사이트 하나에서만 HTTP 오류 반환 | 사이트 제한, 출구 지역, 계정 상태, 서비스 상태 확인 |
문제를 해결한 뒤 규칙 모드와 기존 보안 설정, 필요한 네트워크 인터페이스를 복원하고 구독 업데이트와 자주 사용하는 웹사이트를 다시 테스트하세요. 구독 업데이트가 로컬 설정을 덮어쓴다면 클라이언트에서 지원하는 오버라이드 또는 병합 기능을 사용해 변경 사항을 보존하세요. 편집기의 원본 텍스트만 확인하지 말고 병합 후 실제로 적용되는 설정을 확인해야 합니다.
추가로 도움을 요청할 때는 클라이언트와 코어 버전, 운영체제 버전, 시스템 프록시 또는 TUN 상태, 실제 수신 포트, 테스트 명령, 같은 시간대의 민감 정보를 가린 로그를 함께 제공하세요. 재현 가능한 요청 하나를 중심으로 설명하면 클라이언트를 바로 재설치하는 것보다 문제 위치를 찾기 쉽습니다.