Clash 실행 로그 오류 정리: dial tcp·i/o timeout·no such host 원인과 해결 방법

먼저 실패한 구간을 확인한 다음 오류 키워드를 살펴보세요

dial tcp는 “TCP 연결을 시도한다”는 뜻일 뿐, 오류 원인은 아닙니다. 뒤에 나오는 주소와 포트, 마지막 오류 메시지를 확인해야 합니다. i/o timeout은 네트워크 읽기 또는 쓰기 작업이 제한 시간 안에 끝나지 않았다는 뜻입니다. no such host는 현재 DNS 조회 경로에서 사용할 수 있는 호스트 주소를 찾지 못했다는 뜻입니다. 이 세 가지를 각각 “노드 장애”, “느린 네트워크”, “DNS 변경”으로 단정할 수는 없습니다.

프록시 요청은 일반적으로 “앱 → 로컬 프록시 진입점 → 규칙 및 프록시 그룹 → 노드 서버 → 대상 사이트” 순서로 전달됩니다. DNS 조회는 노드 도메인이나 대상 도메인을 확인하는 등 여러 단계에서 발생할 수 있습니다. 오류가 난 주소가 어느 구간에 속하는지 먼저 파악해야 로컬 포트, 노드 선택, DNS 설정 중 무엇을 점검할지 결정할 수 있습니다.

요청 한 번으로 점검에 필요한 기록 남기기

클라이언트의 ‘로그’ 페이지를 열고 오류가 발생한 시간을 기록하세요. 메뉴 이름은 ‘실행 로그’ 또는 ‘Logs’일 수 있습니다.
현재 모드, 사용 중인 설정 파일 이름, 프록시 그룹에서 실제 선택된 노드, 시스템 프록시와 TUN의 활성화 여부를 기록하세요.
로그 수준을 잠시 debug로 설정한 뒤 오류를 한 번만 재현하세요. 점검이 끝나면 로그가 계속 쌓이지 않도록 info로 되돌리세요.
같은 시각의 규칙 매칭, 출구 노드 선택, 최종 오류를 함께 보관하세요. 빨간색 키워드 하나만 잘라내지 마세요.

자주 발생하는 오류 정리: 원인부터 확인한 뒤 설정 변경

로그 끝부분 또는 키워드	의미	먼저 확인할 항목
`connection refused`	연결 요청이 거부됨	연결 대상 주소와 포트가 맞는지, 서비스가 해당 포트에서 대기 중인지 확인
`i/o timeout`	네트워크 작업이 제한 시간을 초과함	DNS 조회, 노드 연결, 대상 응답 중 어느 단계에서 시간 초과가 발생했는지 확인
`no such host`	도메인 조회 실패	도메인 이름과 철자, 사용 중인 DNS 조회 경로 확인
`address already in use`	로컬에서 사용할 주소와 포트가 이미 사용 중	충돌한 포트와 해당 포트를 사용하는 프로세스 확인
`network is unreachable`	현재 네트워크에 사용할 수 있는 경로가 없음	IPv4/IPv6 경로, 네트워크 인터페이스, 터널 상태 확인
`certificate has expired`	인증서 유효 기간 확인 실패	시스템 시간, 노드 인증서, 서버 점검 여부 확인

오류 한 줄에 여러 단계의 원인이 들어 있을 수 있습니다. 예를 들어 바깥쪽에는 dial failed가 표시되고, 내부 오류에는 DNS 조회 시간 초과가 나올 수 있습니다. 가장 안쪽의 구체적인 오류부터 확인한 다음 어떤 연결에서 발생했는지 바깥쪽으로 따라가세요.

dial tcp와 connection refused: 연결 대상부터 확인

dial tcp 192.0.2.10:443: connect: connection refused

이 로그는 192.0.2.10:443으로 TCP 연결을 시도했지만 거부되었음을 나타냅니다. 서비스가 실행되지 않았거나 포트가 잘못되었거나 네트워크 장비가 연결을 거부했을 수 있습니다. 해당 주소가 노드 서버라면 현재 노드의 server와 port를 확인하세요. 직접 연결할 대상이라면 규칙에 따라 요청이 DIRECT로 전달되는지 확인하세요.

127.0.0.1이 보이면 로컬 프록시 진입점부터 확인

Failed to connect to 127.0.0.1 port 7890: Connection refused

이 메시지는 Clash 로그가 아니라 브라우저나 명령줄 도구에서 나온 것일 수도 있습니다. 보통 앱이 로컬 프록시 진입점에 연결하지 못했다는 뜻으로, 코어가 실행되지 않았거나 진입점 포트가 바뀌었거나 앱에 예전 포트가 설정된 경우에 발생합니다. 클라이언트의 포트 설정에서 실제 수신 포트를 확인한 뒤 시스템 프록시의 주소와 포트를 대조하세요.

mixed-port: 7890: 하나의 포트에서 HTTP 프록시와 SOCKS 프록시 트래픽을 모두 받습니다.
port: HTTP 프록시 진입점, socks-port: SOCKS 프록시 진입점입니다. 포트 번호만 보고 프로토콜을 추측하지 마세요.
external-controller: 제어 인터페이스입니다. 브라우저에서 사용하는 프록시 진입점이 아닙니다.

예를 들어 제어 인터페이스가 127.0.0.1:9090이라고 해서 시스템 프록시에 9090을 입력해야 하는 것은 아닙니다. 프록시 진입점과 제어 인터페이스를 혼동하면 연결 실패, 잘못된 응답, 웹 페이지 로딩 오류가 발생할 수 있습니다.

i/o timeout: DNS, 노드, 대상 사이트를 나눠 테스트

i/o timeout은 네트워크 작업이 제한 시간 안에 완료되지 않았다는 뜻입니다. DNS의 UDP 조회, 노드 서버 연결, 연결 후 읽기 또는 쓰기 작업 중 어디에서든 발생할 수 있습니다. 이 메시지만 보고 노드를 열 개 넘게 바꾸다 보면 실제 로컬 네트워크 문제가 가려질 수 있습니다.

1단계: 프록시 진입점을 지정해 오류 재현

실제 혼합 포트가 7890이라면 아래 명령을 실행할 수 있습니다. Windows PowerShell에서는 일부 환경이 curl을 다른 명령으로 해석할 수 있으므로 curl.exe를 사용하세요. macOS와 Linux에서는 보통 curl을 사용합니다.

curl -I -v --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7890 https://example.com/

여기서 10초는 연결 단계의 제한 시간이고 20초는 전체 작업의 제한 시간입니다. 코어의 기본 시간 초과 값이 아닙니다. -I는 HEAD 요청을 보내며 서버가 405를 반환할 수 있습니다. 유효한 HTTP 응답을 받았다면 해당 상태 코드를 네트워크 시간 초과로 볼 수 없습니다. 응답 본문을 확인하려면 -I를 제거하세요.

2단계: 한 번에 변수 하나만 변경

대상 URL과 규칙은 그대로 둔 채 같은 프록시 그룹에서 정상 작동이 확인된 노드 하나로 바꿔 다시 요청하세요.
노드는 그대로 두고 접속이 허용된 다른 대상을 요청하세요. 한 대상에서만 실패한다면 해당 사이트의 제한이나 관련 규칙을 먼저 확인하세요.
클라이언트 설정은 그대로 유지하고 휴대폰 핫스팟으로 테스트하세요. 핫스팟에서는 정상이고 기존 네트워크에서만 실패해야 기존 네트워크의 경로나 필터를 추가로 점검할 근거가 됩니다.

지연 시간 테스트가 성공해도 모든 웹사이트에 접속할 수 있는 것은 아닙니다. 테스트 URL, 요구되는 HTTP 상태 코드, 실제 서비스 대상은 서로 다를 수 있습니다. 테스트가 실패했다고 노드를 완전히 사용할 수 없다고 단정할 수도 없습니다. 문제가 발생한 실제 요청으로 교차 확인하세요.

no such host: 조회에 실패한 도메인부터 확인

lookup node.example.net: no such host

메시지에 표시된 도메인이 노드의 server라면 프록시 연결이 아직 수립되지 않은 상태입니다. 먼저 노드 도메인의 철자와 구독 만료 여부, 서비스 제공자가 주소를 변경했는지 확인한 다음 해당 도메인의 DNS 조회 경로를 점검하세요. 대상 사이트 도메인에서 오류가 발생했다면 대상 DNS와 규칙을 확인해야 합니다. 구독이 만료되었다고 바로 단정하지 마세요.

다음 세 가지를 순서대로 확인

주소 자체: server에 https://, 경로, 뒤쪽 공백이 포함된 전체 URL을 입력하지 않았는지 확인하세요. 이 필드에는 일반적으로 호스트 이름이나 IP 주소를 입력합니다.
시스템 DNS 조회: nslookup node.example.net을 실행하세요. 이 도메인은 형식 예시이므로 테스트할 때는 로그에 나온 실제 도메인으로 바꾸세요. 조회 요청은 현재 사용 중인 DNS 서버로 전송됩니다.
코어 DNS 조회: 실제 적용 중인 설정의 dns 항목을 확인하고 같은 시각에 DNS 서버 연결 시간 초과나 연결 거부가 발생했는지 살펴보세요.

nslookup 결과는 비교용일 뿐, 코어의 DNS가 정상이라는 것을 증명하지는 않습니다. 시스템 DNS, Clash 내장 DNS, 브라우저의 보안 DNS는 서로 다른 경로를 사용할 수 있습니다. TUN의 DNS 가로채기도 조회 경로를 바꿀 수 있습니다.

“프록시를 통해 암호화 DNS에 접속”하도록 설정했는데 노드 도메인도 그 DNS로 조회해야 한다면 시작 단계에서 의존성 순환이 생길 수 있습니다. 아직 연결되지 않은 프록시로 모든 DNS 요청을 강제로 보내기보다, 먼저 노드 도메인을 조회할 수 있는 경로를 확보하세요.

address already in use: 로컬 포트 충돌 확인 방법

listen tcp 127.0.0.1:7890: bind: address already in use

로컬 수신에 실패한 문제로 노드 요금제나 원격 도메인과는 직접적인 관련이 없습니다. 다른 프록시 클라이언트가 이미 실행 중이거나 이전 코어 프로세스가 제대로 종료되지 않은 경우가 흔합니다. 포트를 사용하는 프로세스를 먼저 확인한 뒤 이전 프로세스를 종료할지 포트를 변경할지 결정하세요. 정체를 모르는 시스템 프로세스를 무작정 종료하지 마세요.

Windows: 포트를 수신 중인 프로세스 찾기

netstat -ano | findstr :7890
tasklist /FI "PID eq 1234"

첫 번째 명령은 해당 포트가 포함된 항목을 표시합니다. 로컬 주소, LISTENING 상태, PID를 확인하세요. 두 번째 명령의 1234는 프로세스 번호 예시이므로 실행할 때는 조회한 실제 PID를 입력해야 합니다. 연결 기록만 있다고 해서 해당 프로그램이 수신 포트를 점유한 것은 아닙니다.

macOS / Linux: 포트 수신 프로세스 확인

lsof -nP -iTCP:7890 -sTCP:LISTEN

Linux에 lsof가 설치되어 있지 않다면 ss -ltnp 'sport = :7890'을 사용해 보세요. 프로세스 정보를 표시하려면 추가 권한이 필요할 수 있습니다. 혼합 포트를 7890에서 7891로 변경한다면 시스템 프록시, 브라우저 확장 프로그램, 터미널 환경 변수, 수동으로 설정한 다른 앱의 진입점도 함께 업데이트해야 합니다.

화면에 ‘실행 중’이라고 표시되어도 모든 진입점이 정상적으로 포트를 수신한다는 뜻은 아닙니다. 시작 후 로그를 확인해 문제가 mixed-port, DNS 수신 포트, 제어 인터페이스 중 어디에 해당하는지 파악하세요. 엉뚱한 설정을 변경하지 않도록 주의하세요.

TUN, 인증서, 연결 끊김: 모두 같은 시간 초과로 취급하지 마세요

network is unreachable: 먼저 주소가 IPv6인지 확인한 뒤 현재 네트워크에 사용할 수 있는 IPv6 경로가 있는지 살펴보세요. 이 오류는 경로 문제에 가깝습니다. 이 한 줄만으로 서버가 오프라인이라고 단정할 수 없습니다.
permission denied 또는 operation not permitted: TUN 장치를 만드는 단계에서 발생했다면 클라이언트의 서비스 모드, 시스템 권한, 다른 VPN의 사용 여부를 확인하세요. 현재 클라이언트의 설치 안내에 따라 필요한 권한을 설정하고 프로그램 전체의 권한을 무작정 높이지 마세요.
x509: certificate has expired or is not yet valid: 먼저 시스템 날짜와 시간, 시간대를 확인한 다음 노드 인증서를 점검하세요. skip-cert-verify: true를 장기적인 해결책으로 사용하지 마세요.
connection reset by peer 또는 EOF: 연결이 초기화되었거나 읽기가 종료되었다는 뜻이며 서버, 프로토콜 설정, 중간 네트워크와 관련이 있을 수 있습니다. 오류 한 줄만으로 비밀번호가 잘못되었다고 판단할 수는 없습니다.

TUN 비교 테스트를 시작하기 전에 기존 상태를 기록하세요. 그런 다음 TUN을 끄고 127.0.0.1:7890을 명시한 요청으로 테스트합니다. 명시적 프록시에서는 정상이고 TUN에서만 실패한다면 경로, DNS 가로채기, 다른 VPN과의 충돌을 집중적으로 확인하세요. TUN을 끈 뒤 브라우저를 바로 여는 것은 같은 테스트가 아닙니다. 브라우저가 시스템 프록시를 사용하거나 프록시 없이 직접 연결할 수 있기 때문입니다.

특정 앱에서만 실패한다면 TCP와 UDP 중 어떤 프로토콜을 사용하는지, 시스템 프록시 설정을 따르는지, 앱 자체 프록시 설정이 있는지 먼저 확인하세요. HTTP 프록시 요청이 성공해도 UDP 전달이 정상이라는 뜻은 아닙니다. 이 때문에 곧바로 전역 모드나 구독 설정 전체를 변경하지 마세요.

수정 후 재검사: 비교할 수 있는 기록 남기기

같은 URL과 요청 방식, 같은 프록시 그룹을 사용해 다시 테스트하고 기존 오류가 사라졌는지 확인하세요.
요청이 의도치 않게 직접 연결로 바뀐 것은 아닌지 로그에서 실제로 적용된 규칙과 출구를 확인하세요.
임시로 변경한 로그 수준과 테스트 옵션을 원래대로 되돌리고 필요한 로컬 설정 변경 사항을 저장하세요.
도움을 요청할 때는 코어 이름과 버전, 운영체제 버전, 오류 발생 시각, 오류 전체 내용과 재현 절차를 제공하세요.

점검 순서는 로컬 진입점 → 규칙에 따른 출구 → 노드 DNS 조회 및 연결 → 대상 응답으로 정하세요. 한 번에 하나씩만 변경하고 같은 요청의 변경 전후 결과를 기록하면 클라이언트를 반복해서 재설치하는 것보다 원인을 쉽게 찾을 수 있습니다. 포트 설정은 시작하기의 포트 안내를 참고하세요. 시간 초과가 계속되면 문제 해결의 시간 초과 점검을 확인하세요.