FlClash 로그 오류 해석: dial tcp 시간 초과·DNS 조회 실패 등 오류 원인 찾기

먼저 실패한 요청 하나를 재현하세요

FlClash 로그는 보통 Clash Meta(mihomo) 커널과 클라이언트 자체에서 생성됩니다. 로그에 warning이 표시된다고 해서 프록시 전체가 작동하지 않는 것은 아닙니다. 백그라운드 앱, 노드 상태 확인, 구독 업데이트, 브라우저 요청이 동시에 로그를 남길 수도 있습니다. 문제를 제대로 진단하려면 실패 기록과 실제 작업을 연결하는 것부터 시작하세요.

현재 설정 이름, 아웃바운드 모드, 정책 그룹에서 선택한 노드, 시스템 프록시와 TUN 모드의 활성화 상태를 기록하세요.
FlClash 로그 페이지를 열고 다른 다운로드를 일시 중지한 뒤, 문제를 안정적으로 재현할 수 있는 주소 하나에만 접속하세요.
작업 시간을 기록하고 전후 약 10초간의 로그를 보관하세요. 대상 도메인과 포트, 적용된 규칙, 정책 그룹, 최종 아웃바운드를 중점적으로 확인하세요.
한 번에 조건 하나만 바꾼 뒤 같은 주소로 다시 시도하세요. 예를 들어 먼저 노드만 바꾸고 DNS와 TUN 스택은 동시에 변경하지 마세요.

아래 로그는 필드를 설명하기 위한 예시이며 실제 측정 결과가 아닙니다. 커널 버전에 따라 필드 순서와 표현이 다를 수 있습니다. 예시의 192.0.2.10은 문서용 주소로, 연결 가능한 노드 주소가 아닙니다. 127.0.0.1:7890도 로컬 포트 예시일 뿐이므로 현재 설정에서 실제로 수신 중인 포트로 바꿔야 합니다.

로그 수준: 요청을 먼저 확인하고 심각도를 살펴보세요

mihomo에서 자주 사용하는 log-level 값은 debug, info, warning, error, silent입니다. 로그 수준은 출력 범위를 정할 뿐, 오류 원인을 뜻하지는 않습니다. warning은 상태 확인 실패일 수 있고, info 로그에서 요청이 잘못된 아웃바운드로 전달된 사실을 발견할 수도 있습니다.

수준	주요 용도	대응 방법
debug	보충 분석, 연결 등 세부 정보 확인	잠시 켜고 문제를 재현한 뒤 원래대로 되돌리기
info	규칙과 아웃바운드 경로 확인	일상적인 문제 해결의 시작점
warning	연결·조회 등의 이상 징후 알림	실패한 요청과 관련 있는지 확인
error	설정 또는 실행 중 발생한 오류	구체적인 오류 내용과 주변 기록부터 확인
silent	커널 로그 출력 억제	문제 해결 중에는 info 또는 debug 사용

더 자세한 로그가 필요하면 클라이언트의 로그 수준 설정에서 잠시 조정하세요. 설정 파일을 수정한다면 최종 적용 설정의 log-level: debug를 확인하세요. 구독 캐시 파일만 수정하면 안 됩니다. 클라이언트가 설정을 다시 생성하거나 구독을 업데이트할 때 변경 사항이 덮어써질 수 있습니다. 점검을 마친 뒤에는 info로 되돌려 요청 정보가 계속 기록되지 않도록 하세요.

dial tcp 시간 초과: 연결 대상부터 확인하세요

dial tcp 192.0.2.10:443: i/o timeout
dial tcp 127.0.0.1:7890: connect: connection refused

dial tcp는 TCP 연결을 설정한다는 뜻입니다. 뒤에 표시된 timeout만 볼 것이 아니라 앞에 나온 주소가 프록시 노드인지, 직접 연결 대상인지, 로컬 프록시 서비스인지 확인해야 합니다. 프록시를 사용하면 오류에 노드 서버 주소가 표시될 수 있고, DIRECT로 연결하면 대상 웹사이트 주소가 표시될 수 있습니다. 이 한 줄만으로 “사이트가 차단됐다”거나 “구독이 만료됐다”고 단정할 수는 없습니다.

i/o timeout과 connection refused의 차이

i/o timeout: 제한 시간 안에 연결 또는 관련 네트워크 작업이 완료되지 않았다는 뜻입니다. 노드에 연결할 수 없거나 패킷 손실, 라우팅 이상, 방화벽의 무응답 차단 등이 원인일 수 있습니다.
connection refused: 연결이 거부됐다는 응답을 받은 상태입니다. 해당 포트에서 서비스가 대기 중이지 않거나, 서버 포트 설정이 맞지 않거나, 기기에서 연결을 명시적으로 거부할 때 흔히 발생합니다.
network is unreachable: 현재 시스템에 대상 네트워크로 연결되는 사용 가능한 경로가 없다는 뜻입니다. IPv6 주소에서만 나타난다면 기기의 IPv6 연결 상태를 따로 확인하세요.

두 가지 비교 테스트로 원인을 좁히세요

네트워크는 그대로 둔 채 다른 노드를 직접 선택하고 새 요청을 보내세요. 특정 노드 하나에서만 계속 시간 초과가 발생한다면 해당 노드의 서버 주소와 포트, 서비스 상태를 먼저 확인하세요. 노드는 그대로 두고 Wi-Fi를 휴대폰 핫스팟으로 바꿔 테스트할 수도 있습니다. 원래 네트워크에서만 실패한다면 로컬 인터넷 연결이나 통신사 경로를 살펴보세요. 이런 비교 테스트는 범위를 좁히는 데 도움이 되지만 특정 기기의 고장을 단독으로 입증하지는 않습니다.

노드 지연 시간 테스트에 성공해도 모든 사이트에 접속할 수 있다는 뜻은 아닙니다. 테스트는 보통 지정된 확인 주소와 단일 연결 경로만 확인하므로 실제 서비스 요청을 대신할 수 없습니다. 정책 그룹을 전환해도 기존 장시간 연결은 이전 아웃바운드를 계속 사용할 수 있습니다. 판단하기 전에 페이지를 새로고침하거나 연결을 다시 설정하세요.

DNS 조회 실패: 노드 도메인과 웹사이트 도메인을 구분하세요

lookup example.com: no such host
dns resolve failed: context deadline exceeded

no such host는 보통 조회 과정에서 해당 이름이 존재하지 않거나 사용할 수 있는 주소를 얻지 못했다는 뜻입니다. context deadline exceeded는 관련 작업이 제한 시간을 넘겼다는 뜻입니다. 후자는 DNS에만 해당하는 오류가 아니므로 주변 DNS 필드와 함께 확인해야 합니다. 먼저 실패한 도메인이 노드 서버인지 접속하려는 대상인지 구분하세요. 두 경우는 영향을 미치는 범위가 다릅니다.

노드 서버 도메인 조회 실패

프록시 연결을 설정하려면 먼저 노드 주소를 조회해야 합니다. 노드 주소를 조회하는 DNS 업스트림이 다시 해당 노드를 거쳐야 하도록 설정되어 있으면 의존성 순환이 발생할 수 있습니다. 실제 적용 설정에서 proxy-server-nameserver 등 노드 도메인 조회 설정을 확인하고, 관련 DNS 업스트림에 연결 가능한 초기 경로가 있는지 살펴보세요. 아직 설정되지 않은 프록시를 통해 모든 DNS 요청을 무작정 보내지 마세요.

대상 웹사이트 도메인 조회 실패

dns 섹션의 nameserver, nameserver-policy와 사용 중인 경우 fallback을 확인하세요. respect-rules가 활성화되어 있다면 DNS 요청이 따르는 규칙 경로도 점검해야 합니다. DoH 주소는 HTTPS 요청으로 작동하지만, 주소가 https://로 시작한다고 해서 현재 네트워크에서 반드시 접속할 수 있는 것은 아닙니다.

특정 도메인만 실패하는 경우: 철자, 도메인별 조회 정책, DNS 업스트림 응답을 확인하세요.
모든 대상 도메인 조회에 실패하지만 노드는 연결되는 경우: 대상 도메인의 조회 경로와 DNS 업스트림을 먼저 확인하세요.
TUN을 켠 뒤에만 실패하는 경우: DNS 가로채기, 시스템 리졸버, 다른 네트워크 소프트웨어의 트래픽 처리 관계를 확인하세요.

핸드셰이크 실패: 인증서, 프로토콜, 연결 종료를 구분하세요

tls: failed to verify certificate: x509: certificate has expired or is not yet valid
tls: first record does not look like a TLS handshake
EOF

TCP 연결에 성공했다는 것은 전송 계층의 진입점에 도달했다는 뜻일 뿐입니다. 이후 노드 프로토콜, TLS, 인증, 대상 웹사이트 연결 단계에서 실패할 수 있습니다. 로그의 TLS 오류는 프록시 전송, DNS 업스트림 또는 다른 HTTPS 요청에서 발생했을 수 있으므로 먼저 오류가 발생한 대상을 확인하세요.

인증서가 만료됐거나 아직 유효하지 않음: 먼저 시스템 날짜와 시간, 시간대를 확인한 뒤 서버 인증서의 유효 기간을 살펴보세요. 기기 시간이 맞지 않아도 인증에 실패할 수 있습니다.
인증서 이름이 일치하지 않음: 노드의 servername, 실제 서버 인증서, 구독 매개변수가 서로 일치하는지 확인하세요. 필요한 도메인 이름을 임의로 서버 IP 주소로 바꾸지 마세요.
첫 번째 기록이 TLS처럼 보이지 않음: TLS를 지원하지 않는 서비스에 연결했거나 중간 장비가 다른 내용을 반환했을 수 있습니다. 포트와 TLS 설정을 확인하세요. 이 메시지만으로 비밀번호가 틀렸다고 단정할 수는 없습니다.
EOF 또는 connection reset by peer: 상대편에서 연결을 닫았거나 연결이 초기화됐다는 뜻입니다. 이 메시지만으로 종료 원인을 알 수 없으므로 핸드셰이크 전후 기록과 서버 상태를 함께 확인해야 합니다.

구독을 업데이트한 뒤 같은 종류의 노드가 모두 실패한다면 먼저 클라이언트에 포함된 커널이 해당 프로토콜과 매개변수를 지원하는지 확인한 다음, 구독 제공자가 안내한 설정 요구 사항을 점검하세요. skip-cert-verify: true를 만능 해결책으로 사용하지 마세요. 인증서 검증을 건너뛰면 신원 확인이 약해질 뿐 아니라 포트, 인증, 전송 방식이 맞지 않는 문제도 해결되지 않습니다.

규칙 미일치: 모드를 확인한 뒤 최종 아웃바운드를 살펴보세요

“규칙 미일치”는 사용자가 현상을 설명할 때 쓰는 표현인 경우가 많으며, 고정된 커널 오류를 뜻하지는 않습니다. Rule 모드에서는 보통 규칙을 순서대로 확인해 일치하는 규칙의 정책을 사용합니다. GLOBAL 및 DIRECT 모드에서는 일반 규칙 목록에 따라 트래픽을 분기하지 않습니다. 먼저 현재 모드를 확인하고 연결 기록의 매칭 유형과 정책 경로를 살펴보세요.

proxy-groups:
  - name: Web
    type: select
    proxies:
      - DIRECT

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

아래 내용은 규칙 간 관계를 보여 주는 예시이며, 그대로 사용할 수 있는 완전한 구독 설정이 아닙니다. www.example.com에 접속하면 DOMAIN-SUFFIX 규칙에 일치해 Web 정책 그룹으로 전달되지만, 여기서 해당 그룹에는 DIRECT만 있어 최종적으로 직접 연결됩니다. 따라서 “프록시 그룹 규칙에 일치했다”는 것이 “원격 프록시 노드를 거쳤다”는 뜻은 아닙니다. 실제 문제를 확인할 때는 규칙 이름에서 멈추지 말고 정책 그룹에서 현재 선택된 항목까지 확인하세요.

로그에 MATCH가 표시되는 경우: 앞선 규칙이 해당 도메인에 먼저 적용되는지, 외부 규칙 세트가 정상적으로 로드됐는지, 앱이 연결할 때 도메인 정보가 유지됐는지 확인하세요.
도메인 규칙이 적용되지 않는 경우: 앱이 IP 주소로 직접 연결했을 수 있습니다. 스니핑으로 모든 프로토콜의 도메인을 복원할 수 있는 것은 아니므로 항상 해결된다고 기대해서는 안 됩니다.
규칙이 REJECT를 가리키는 경우: 의도적으로 차단된 것인지 확인하세요. 이 경우에는 노드를 바꾸기보다 규칙의 의도에 맞게 처리해야 합니다.
설정을 바꿨는데도 이전 경로를 사용하는 경우: 현재 실행 중인 Profile이 방금 수정한 Profile인지 확인하고 새 연결로 다시 테스트하세요.

규칙 참조 관계를 정리하려면 이 사이트의 고급 설정의 규칙 설명을 참고하세요. 구독 규칙을 수정하기 전에 변경 사항을 유지하는 방법을 확인해 구독 업데이트로 로컬 변경 사항이 덮어써지지 않도록 하세요.

TUN 및 포트 오류: 기기의 진입점을 확인하세요

listen tcp 127.0.0.1:7890: bind: address already in use
operation not permitted

address already in use는 수신 주소와 포트가 충돌했다는 뜻입니다. 다른 프록시 클라이언트를 종료하고 이전 프로세스가 계속 실행 중인지 확인한 다음 FlClash에서 실제로 사용하는 포트를 살펴보세요. 수신 포트를 바꿨다면 시스템 프록시와 프록시 주소를 직접 입력한 앱도 함께 확인해야 합니다. 설정의 숫자 하나만 바꾸면 충분하지 않습니다.

가상 네트워크 인터페이스를 만들거나 라우팅을 변경하는 과정에서 operation not permitted가 발생하면 우선 권한을 확인하세요. 데스크톱에서 TUN을 사용하려면 관리자 권한이나 클라이언트에 포함된 보조 서비스가 필요할 수 있습니다. Android에서는 VPN 연결 권한을 허용해야 합니다. 다른 VPN이나 보안 소프트웨어가 네트워크 트래픽을 처리하고 있을 수도 있습니다.

현재 상태를 기록하고 다른 VPN 및 프록시 클라이언트를 잠시 종료하세요.
TUN을 끄고 시스템 프록시만 사용해 브라우저를 테스트하여 노드와 기본 프록시 진입 경로가 정상인지 확인하세요.
그다음 TUN만 켜고 가상 네트워크 인터페이스, 권한, 라우팅 오류가 발생하는지 살펴보세요.
TUN을 사용할 때만 실패한다면 기기의 트래픽 처리 경로부터 확인하세요. 구독과 DNS를 모두 바로 초기화할 필요는 없습니다.

시스템 프록시 테스트에 성공해도 해당 테스트에 참여한 앱의 경로만 정상이라는 뜻입니다. 모든 UDP 트래픽, 게임, 백그라운드 프로그램이 프록시를 사용할 수 있다는 보장은 없습니다. 운영체제와 커널 지원 여부를 고려해 TUN 스택을 하나씩 비교해야 하며, 모든 기기에 가장 적합한 단일 설정은 없습니다.

문제 해결 정보 제출: 주변 기록은 유지하고 인증 정보는 숨기세요

도움이 되는 제보에는 화면 가득한 error 로그만 첨부하는 대신 문제를 재현할 수 있는 정보가 담겨야 합니다. 운영체제와 아키텍처, FlClash 버전, 커널 버전, 현재 모드, TUN 상태, 오류 발생 시간, 노드와 네트워크를 바꿔 본 비교 결과를 함께 제공하세요. 버전 정보는 클라이언트에 실제로 표시되는 값을 기준으로 하며, 문서 게시일을 버전 근거로 삼지 마세요.

작업: 예: “같은 HTTPS 주소를 열고 새 연결을 시작한 뒤 약 10초 후 실패함.” 초 단위 시간은 실제로 확인한 결과를 적으세요.
범위: 노드 하나에서만 실패하는지, 모든 노드에서 실패하는지와 웹사이트 하나에서만 실패하는지, 대부분의 사이트에서 실패하는지를 구분하세요.
로그: 규칙, 아웃바운드, 최종 오류를 포함해 문제 발생 전후의 관련 로그를 보관하세요. 마지막 한 줄만 캡처하지 마세요.
개인정보: 구독 링크, 토큰, 비밀번호, UUID, 민감한 도메인을 숨기세요. 구독 설정 전체를 공개하지 마세요.

마지막으로 연결 단계별로 원인을 분류하세요. 요청 기록이 없으면 트래픽 진입 경로를 확인하고, 노드 도메인 조회에 실패하면 초기 DNS 경로를 살펴보세요. 노드 TCP 연결이 시간 초과되면 노드와 네트워크를 확인하고, 핸드셰이크에 실패하면 프로토콜과 인증서를 점검하세요. 아웃바운드가 예상과 다르면 모드, 규칙, 정책 그룹을 확인하세요. 여러 설정을 한꺼번에 바꾸기보다 같은 요청을 따라 단계별로 확인하는 편이 결과를 재현하기 쉽습니다.