Clash 연결 실패 점검 체크리스트: 포트 점유부터 시스템 프록시까지 항목별 확인

Clash 코어 오류, 브라우저에서 웹페이지가 열리지 않는 문제, 구독을 분명히 업데이트했는데도 연결이 안 되는 문제—이런 증상의 원인은 대체로 다섯 가지 영역에 집중됩니다: 로컬 포트 점유 여부, 시스템 프록시 스위치가 실제로 적용되었는지, 현재 노드가 사용 가능한지, DNS 해석이 가로채기나 오염을 당했는지, 그리고 방화벽이나 보안 소프트웨어가 코어 프로세스를 차단하고 있는지입니다. 하나씩 점검하는 것이 클라이언트를 반복해서 재시작하는 것보다 훨씬 시간을 절약합니다. 이 체크리스트는 안에서 바깥 순서로 구성되어 있습니다: 먼저 코어 자체가 포트를 정상적으로 리스닝할 수 있는지 확인하고, 그다음 시스템 레벨에서 트래픽을 코어로 제대로 전달하고 있는지 확인하며, 마지막으로 전달된 트래픽이 실제로 목표 사이트에 도달할 수 있는지 확인합니다.

NOTE / 설명

본 글은 Clash Meta 코어(mihomo) 및 주요 GUI 클라이언트(Clash Verge, Clash for Windows 계열 포크, ClashX Meta 등)를 기준으로 작성되었으며, 명령줄 예시는 Windows, macOS, Linux 세 플랫폼으로 구분되어 있습니다. 작업 전에 클라이언트를 완전히 종료한 뒤 한 번 재시작해서 일시적인 오류를 배제해 주세요.

1단계: 로컬 포트 점유 확인

Clash 코어는 기본적으로 믹스 포트(보통 7890), 컨트롤 패널 포트(9090), 그리고 일부 클라이언트가 사용하는 DNS 포트(53 또는 1053)를 리스닝합니다. 이 포트들이 다른 프로그램에 이미 점유되어 있으면 코어가 시작에 실패하거나 조용히 저하된 상태로 동작하는데, 이 경우 클라이언트 화면에는 "실행 중"이라고 표시되지만 실제로는 트래픽이 지나가지 않습니다.

Windows

netstat -ano | findstr "7890"
netstat -ano | findstr "9090"

출력 결과의 마지막 열이 프로세스 PID이며, 작업 관리자나 tasklist /FI "PID eq 프로세스번호" 명령으로 해당 프로세스가 무엇인지 확인할 수 있습니다. 포트가 Clash가 아닌 다른 프로세스에 점유되어 있다면 클라이언트 설정에서 믹스 포트를 7891 등 사용 가능한 값으로 변경하거나, 점유 중인 프로세스를 종료한 뒤 코어를 재시작하세요.

macOS / Linux

lsof -i:7890
lsof -i:9090

이 명령어는 해당 포트를 리스닝 중인 프로세스 이름과 PID를 출력합니다. 출력이 비어 있다면 코어가 해당 포트를 정상적으로 리스닝하지 못했다는 뜻이므로, 클라이언트 로그 패널로 돌아가 코어 시작 오류를 확인해야 합니다. 흔한 원인은 설정 파일의 포트 필드 오타나 유효 범위를 벗어난 포트 번호입니다.

2단계: 시스템 프록시 스위치 상태 확인

클라이언트 화면의 "시스템 프록시" 스위치는 본질적으로 시스템의 프록시 설정 필드를 기록하는 것일 뿐, 코어를 직접 제어하지는 않습니다. 스위치가 "켜짐"으로 표시된다고 해서 시스템이 실제로 이 설정을 적용했다는 보장은 없습니다. 흔히 보안 소프트웨어가 스위치를 초기화하거나, 시스템에 여러 네트워크 설정(예: VPN과 Wi-Fi 동시 존재)이 있어 프록시가 잘못된 네트워크 인터페이스에 기록되는 경우가 있습니다.

Windows 검증

reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyEnable
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyServer

ProxyEnable 값이 0x1이면 시스템 프록시가 활성화된 상태이며, ProxyServer는 127.0.0.1:7890과 같은 주소로 표시되어야 합니다. 이 주소가 클라이언트가 실제로 리스닝 중인 포트와 다르다면, 클라이언트에서 시스템 프록시 스위치를 다시 한번 껐다 켜서 값을 새로 기록하세요.

macOS 검증

networksetup -getwebproxy Wi-Fi
networksetup -getsecurewebproxy Wi-Fi

현재 유선 네트워크를 사용 중이라면 Wi-Fi를 Ethernet 또는 해당 인터페이스 이름으로 바꾸세요(먼저 networksetup -listallnetworkservices로 인터페이스 목록을 확인할 수 있습니다).

Linux 검증

대부분의 Linux GUI 클라이언트는 시스템 레벨 프록시를 직접 수정하지 않고, 데스크톱 환경이나 브라우저 확장 프로그램이 환경 변수를 읽는 방식에 의존합니다. 다음을 직접 확인해 보세요:

echo $http_proxy
echo $https_proxy

값이 비어 있다면 네트워크 설정이나 셸 설정 파일에서 시스템 프록시를 수동으로 선언해야 하거나, TUN 모드로 전환해 시스템 프록시 레이어를 우회하고 트래픽을 직접 인수하는 방법을 고려해야 합니다.

3단계: 노드 가용성 확인

시스템 프록시가 정상 적용되었다고 해서 노드가 통한다는 보장은 없습니다. 구독 노드가 만료되었거나, 서버가 일시 점검 중이거나, 현재 선택한 노드의 지연 테스트가 타임아웃으로 표시되는 경우가 흔합니다. 점검 순서는 먼저 클라이언트 노드 목록의 지연 수치를 확인한 뒤, 콘솔에서 목표 노드를 개별적으로 다시 테스트하는 것을 권장합니다.

지연 열에 "타임아웃" 또는 "N/A"가 표시됨: 해당 노드는 현재 사용할 수 없는 상태이므로, 먼저 지연이 정상인 대체 노드로 전환하세요.
모든 노드의 지연이 비정상임: 대부분 구독 전체가 만료되었거나 로컬 네트워크 자체가 끊긴 경우입니다. 먼저 프록시를 거치지 않고도 인터넷에 정상적으로 접속되는지 확인하세요.
지연은 정상이지만 여전히 목표 사이트에 접속할 수 없음: 해당 노드가 목표 사이트로부터 개별적으로 차단당했을 가능성이 있으므로, 출구 지역을 바꿔 시도해 보세요.

컨트롤 패널 API를 통해서도 노드 연결 상태를 확인할 수 있습니다. 단, 설정에서 컨트롤 포트가 열려 있어야 합니다:

curl -x http://127.0.0.1:7890 https://www.google.com -I --max-time 5

HTTP/2 200 또는 30x 상태 코드가 반환되면 프록시 경로 자체는 정상적으로 연결된 상태입니다. 명령이 타임아웃되거나 연결이 거부된다면 문제는 브라우저나 애플리케이션이 아니라 프록시 경로 자체에 있는 것이므로, 브라우저 설정을 반복해서 확인하는 대신 노드나 구독 쪽 점검으로 돌아가야 합니다.

CAUTION / 주의

구독 링크가 연결된 구독 서비스 제공업체에 단일 계정 기기 수 제한이 있는 경우, 같은 구독을 여러 기기에서 동시에 사용하면 일부 제공업체가 새로운 연결을 무작위로 거부합니다. 이 경우 노드 지연은 정상인데도 요청이 계속 실패하는 증상으로 나타나므로, 이런 상황이 의심되면 먼저 다른 기기에서 클라이언트를 종료한 뒤 다시 테스트해 보세요.

4단계: DNS 해석 확인

Clash는 설정 파일에서 별도의 DNS 서버를 지정하거나 fake-ip 또는 redir-host 모드를 활성화할 수 있습니다. 로컬 시스템 DNS와 Clash 내장 DNS가 충돌하면 흔히 웹페이지는 열리지만 로딩이 느리거나, 일부 도메인이 계속 잘못된 IP로 해석되는 증상이 나타납니다.

현재 적용 중인 DNS 확인

# Windows
nslookup www.google.com

# macOS / Linux
nslookup www.google.com
dig www.google.com +short

fake-ip가 활성화되어 있다면 해석 결과는 보통 예약 대역인 198.18.0.0/16에 속합니다. 이는 정상적인 현상으로, 프록시는 전송 계층에서 도메인 기준으로 연결을 다시 수립하므로 해석 오류를 의미하지 않습니다. 결과가 실제 공인 IP 대역에 속하는데도 사이트가 여전히 열리지 않는다면, 해당 도메인이 잘못된 분기 규칙에 걸려 프록시가 아닌 다이렉트 경로로 빠졌는지 추가로 확인해야 합니다.

Clash 내장 DNS가 정상적으로 호출되는지 검증

nslookup www.google.com 127.0.0.1 -port=1053

포트 번호는 설정 파일의 dns.listen 필드와 일치해야 합니다. 이 명령이 타임아웃된다면 코어의 DNS 모듈이 정상적으로 시작되지 않았다는 뜻이므로, 설정 파일로 돌아가 dns.enable이 true로 설정되어 있는지, 그리고 상위 DNS 서버 주소에 접근 가능한지 확인하세요.

5단계: 방화벽 및 보안 소프트웨어 차단 확인

운영체제 기본 방화벽, 서드파티 보안 소프트웨어, 기업 내부 네트워크의 단말 관리 소프트웨어는 모두 Clash 코어 프로세스를 대상으로 차단을 걸 수 있습니다. 이런 차단은 대개 명확한 오류 메시지 없이 연결 요청이 조용히 폐기되는 형태로 나타나므로, 점검 시 노드 문제로 오판하기 쉽습니다.

Windows Defender 방화벽

netsh advfirewall firewall show rule name=all | findstr /i "clash"

일치하는 결과가 없다면 방화벽에 Clash 코어를 허용하는 규칙이 없다는 뜻입니다. "앱이 Windows Defender 방화벽을 통과하도록 허용" 설정에서 클라이언트 실행 파일과 코어 프로세스(일반적으로 파일명은 clash-meta.exe 또는 mihomo.exe)에 대해 개인 네트워크와 공용 네트워크 모두 수동으로 체크해 주세요.

macOS 애플리케이션 방화벽

경로는 "시스템 설정 → 네트워크 → 방화벽 → 옵션"입니다. Clash 클라이언트와 그 코어 프로세스의 상태가 "수신 연결 허용"으로 설정되어 있는지 확인하세요. 일부 보안 소프트웨어(예: 기업용 EDR)는 시스템 방화벽과 별개로 자체적으로 차단을 걸기도 하므로, 해당 소프트웨어의 신뢰 목록에도 추가로 허용을 등록해야 합니다.

Linux iptables / ufw

sudo iptables -L -n | grep 7890
sudo ufw status verbose

프록시 포트를 대상으로 하는 DROP이나 REJECT 규칙이 없는지 확인하세요. TUN 모드를 사용 중이라면 가상 네트워크 카드에 대응하는 라우팅 테이블 항목이 올바르게 기록되어 있는지도 확인해야 합니다. ip route 명령으로 utun 또는 tun0을 가리키는 기본 라우트가 존재하는지 확인할 수 있습니다.

항목별 체크리스트

위 다섯 단계를 바로 대조해서 사용할 수 있는 체크리스트로 정리하면 다음과 같습니다:

믹스 포트(7890)와 컨트롤 포트(9090)가 다른 프로세스에 점유되지 않았고, 코어 로그에 포트 충돌 오류가 없다.
시스템 프록시 필드(ProxyServer / networksetup 출력)가 클라이언트가 실제로 리스닝 중인 포트와 일치한다.
현재 선택된 노드의 지연이 정상이거나, 지연이 정상인 대체 노드로 전환했다.
curl -x 테스트에서 프록시를 통해 목표 사이트에 정상적으로 접속되며 유효한 HTTP 상태 코드가 반환된다.
DNS 해석 결과가 예상대로다(fake-ip 대역 또는 올바른 실제 IP이며, 잘못된 분기 규칙에 걸리지 않았다).
시스템 방화벽과 보안 소프트웨어 모두 Clash 클라이언트와 코어 프로세스에 네트워크 권한을 허용했다.
TUN 모드를 사용한다면 가상 네트워크 카드의 라우팅 테이블 항목이 올바르게 기록되어 있고, 다른 VPN이 기본 라우트를 가로채지 않았다.

STOP / 경고

위 일곱 항목을 모두 통과했는데도 특정 사이트에 여전히 접속할 수 없다면, 대부분은 목표 사이트가 프록시 출구 IP 대역을 개별적으로 차단하거나 캡차로 막고 있는 경우입니다. 이는 사이트 측 정책 문제이므로, 로컬 네트워크 설정을 계속 반복해서 조정할 필요는 없습니다.

이 체크리스트를 로컬 메모로 저장해 두고, 연결 문제가 발생할 때마다 순서대로 확인하는 것을 권장합니다. 무작정 재시작, 노드 변경, 클라이언트 재설치를 반복하는 것보다 훨씬 효율적입니다. 대부분의 연결 실패는 처음 두 단계(포트와 시스템 프록시)만 확인해도 원인을 찾을 수 있으며, 나머지 노드·DNS·방화벽 세 단계는 소수의 까다로운 상황을 해결하는 데 사용됩니다.