노드 연결 시간 초과·접속 오류 해결 방법

1. 속도 측정 시간 초과와 실제 연결 실패 구분하기

FlClash의 지연 시간 측정은 일반적으로 노드 서버에 ping을 보내는 방식이 아니라, 노드를 통해 지정된 테스트 주소에 요청을 보냅니다. ‘시간 초과’는 제한 시간 안에 탐색이 끝나지 않았다는 뜻입니다. 노드 진입점, 도메인 확인, 프로토콜 핸드셰이크에 문제가 있을 수도 있고 테스트 사이트에 접속할 수 없는 경우일 수도 있습니다. 먼저 증상을 기록한 다음 확인할 계층을 정하세요.

2. 로컬 네트워크: 프록시 기능을 끈 상태에서 직접 연결 확인하기

먼저 FlClash에서 시스템 프록시와 TUN을 끈 다음, 평소 직접 접속할 수 있는 사이트를 열어 보세요. 운영체제에 수동 프록시 설정이 남아 있다면 함께 확인해 원래대로 되돌려야 합니다. 클라이언트를 종료하기만 하면 로컬 포트를 가리키는 프록시 설정이 남을 수 있습니다. 이 경우 브라우저가 더 이상 연결을 받지 않는 포트에 접속하려고 해 네트워크 전체가 끊긴 것처럼 보입니다.

네트워크 접속과 시스템 시간 확인

1. 네트워크 인증을 완료하세요. 호텔, 학교 또는 공용 Wi-Fi는 브라우저에서 먼저 인증해야 할 수 있습니다. 시스템에 ‘네트워크 로그인이 필요합니다’라는 알림이 표시되는지 확인하세요.
2. 시스템 프록시를 확인하세요. Windows 11에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 수동 프록시와 설정 스크립트를 확인합니다. macOS에서는 ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 → ‘세부사항’ → ‘프록시’로 이동하세요.
3. 시스템 시간을 맞추세요. Windows 11에서는 ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’에서 확인할 수 있습니다. 날짜, 시간대 또는 시계가 맞지 않으면 TLS 인증서 확인이나 일부 프록시 프로토콜 인증에 영향을 줄 수 있습니다.
4. 다른 네트워크로 연결해 보세요. 노드는 그대로 둔 채 컴퓨터를 기존 Wi-Fi에서 휴대폰 핫스팟으로 바꿔 보세요. 핫스팟에서는 연결된다면 기존 네트워크의 DNS, 방화벽 또는 외부 연결 제한을 우선 확인하세요.

일반 웹사이트에 직접 접속할 수 있다는 사실은 기본적인 인터넷 연결만 확인해 줄 뿐, 노드 포트에 연결할 수 있다는 뜻은 아닙니다. 반대로 ping 응답이 없더라도 서버가 오프라인이라는 증거는 아닙니다. 서버나 네트워크 사업자가 ICMP를 차단할 수 있기 때문입니다. 다음 단계에서는 구독에 설정된 서버 주소와 실제 포트를 확인해야 합니다.

3. 구독 상태: 다운로드 성공, 설정 적용, 계정 사용 가능 여부 확인

FlClash의 ‘프로필’ 페이지에서 현재 사용하는 구독을 찾아 수동으로 업데이트하고, 선택된 프로필이 해당 구독인지 확인하세요. 버전에 따라 버튼 이름이 다를 수 있으므로 현재 화면을 기준으로 확인합니다. 업데이트가 끝나면 ‘프록시’ 페이지에서 노드 목록과 선택한 정책 그룹을 확인해 오래된 설정이나 다른 그룹의 노드를 측정하는 일이 없도록 하세요.

세 가지 단계로 확인

• 구독 요청: HTTP 401 또는 403 응답이면 링크 인증 정보와 서버 접근 제한을 확인하세요. 404 응답이면 주소가 만료되었거나 경로가 바뀌었는지 확인합니다. HTTP 200은 요청이 성공했다는 뜻일 뿐, 응답이 설정 파일이 아니라 로그인 페이지일 수도 있습니다.
• 설정 파싱: 로그에 YAML 구문 오류, 알 수 없는 프록시 유형 또는 설정 로드 실패가 있는지 확인하세요. 다른 클라이언트용 공유 링크는 mihomo 전체 설정으로 바로 가져올 수 없는 경우가 있습니다.
• 서비스 계정: 구독 제공업체 페이지에서 만료일, 잔여 데이터, 기기 수 제한, 점검 공지를 확인하세요. 계정이 만료되어도 로컬에는 노드 목록이 그대로 남아 있을 수 있습니다.

설정에 원격 프록시 그룹이 포함되어 있다면 해당 그룹의 업데이트 성공 여부도 확인하세요. 기본 설정을 다운로드했다고 해서 모든 원격 리소스가 갱신되는 것은 아닙니다. 다시 가져와야 한다면 구독 가져오기 안내를 참고하세요. 구독 출처에 관한 설명은 구독 출처와 사용 범위에서 확인할 수 있습니다.

4. 시스템 프록시와 TUN: 요청이 FlClash로 전달되는지 확인

시스템 프록시는 시스템 프록시 설정을 따르는 앱에 주로 적용됩니다. TUN은 가상 네트워크 인터페이스와 라우팅을 통해 트래픽을 전달합니다. 두 방식은 문제를 확인하는 시작점이 다릅니다. 여러 클라이언트, 브라우저 프록시 확장 프로그램, TUN을 한꺼번에 켜기보다는 한 가지 방식만 선택해 최소한으로 확인하는 편이 원인을 찾기 쉽습니다.

데스크톱: 로컬 프록시 포트부터 확인

TUN을 끄고 FlClash 코어는 실행한 상태로 둔 다음, 클라이언트에 표시된 실제 수신 주소, 혼합 포트, 시스템 프록시 스위치를 확인하세요. 아래에서는 로컬 혼합 포트 7890을 예로 듭니다. 설정에서 다른 포트를 사용한다면 실제 값으로 바꿔야 합니다. 튜토리얼만 보고 포트 번호를 추측하지 마세요.

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

Windows PowerShell에서는 명령 앞부분을 curl.exe로 바꾸면 됩니다. 이전 환경에서 curl이 다른 명령으로 해석되는 문제를 피할 수 있습니다. 명령을 실행하는 동안 FlClash의 연결 기록도 확인하세요. HTTP 응답이 돌아오면 해당 프록시 요청이 대상에 도달한 것입니다. 로컬 포트에서 연결을 거부하면 먼저 수신 포트, 코어 실행 상태 또는 포트 충돌을 확인하세요.

• 명령은 작동하지만 브라우저는 연결되지 않음: 시스템 프록시, 브라우저 확장 프로그램, 브라우저 자체 프록시 설정, 다른 자동 프록시 스크립트 사용 여부를 확인하세요.
• 연결은 클라이언트에 들어오지만 출구가 잘못됨: ‘프록시’ 페이지의 모드와 정책 그룹 선택을 확인하세요. 규칙 모드에서는 대상이 DIRECT로 지정될 수 있습니다. 속도 측정이 성공해도 실제 웹페이지가 해당 노드를 사용하는 것은 아닙니다.
• 연결 기록에 요청이 전혀 없음: 먼저 앱이 프록시를 우회하는지 확인하세요. 이 단계에서는 원격 노드 설정을 계속 바꾸지 마세요.

TUN 사용 시: 권한, 라우팅, VPN 충돌 확인

다른 VPN이나 유사한 TUN 클라이언트를 중지하고, 시스템 안내에 따라 필요한 권한을 부여한 뒤 FlClash의 TUN만 켜세요. 로그에서 가상 인터페이스 생성 실패, 권한 부족 또는 라우팅 설정 실패가 보고되는지 확인합니다. 데스크톱 환경에서는 시스템과 버전에 따라 관리자 권한이나 클라이언트에서 제공하는 서비스가 필요할 수 있습니다.

Android에서는 VPN 연결 요청을 승인했는지 확인하고, 앱 접근 제어에서 대상 앱이 제외되어 있지 않은지 살펴보세요. 시스템에 다른 ‘항상 켜져 있는 VPN’ 또는 ‘VPN 없이 연결 차단’ 설정이 있는지도 확인해야 합니다. 방화벽을 장기간 꺼 두는 방식으로 테스트하지 마세요. 차단 로그를 확인하고 신뢰할 수 있는 클라이언트에 범위를 제한한 규칙을 설정할 수 있습니다.

5. DNS 설정: 노드 도메인과 대상 도메인을 따로 확인

프록시 연결에는 보통 두 종류의 DNS 조회가 있습니다. 하나는 노드 서버 도메인을 진입 IP로 확인하는 과정이고, 다른 하나는 접속하려는 웹사이트 도메인을 처리하는 과정입니다. 노드 진입점의 DNS 확인에 실패하면 프록시 서버에 연결되기 전부터 문제가 생깁니다. 대상 도메인 확인에 실패하면 노드 속도 측정은 정상인데 일부 웹페이지가 열리지 않을 수 있습니다. 로그에 표시된 호스트 이름을 함께 확인해 원인을 구분하세요.

먼저 시스템 DNS 조회 결과와 비교

nslookup example.com

명령에 입력한 도메인을 실제로 오류가 발생한 웹사이트 도메인이나 설정에 있는 노드 서버 도메인으로 바꾸세요. 시간 초과, 레코드 없음, 예상과 다른 주소 응답은 각각 다른 원인을 가리킵니다. nslookup 결과는 해당 조회가 사용한 DNS 경로만 보여 주며 mihomo의 최종 결과와 같다고 볼 수 없습니다. TUN DNS 가로채기가 켜져 있으면 조회가 클라이언트로 전달될 수도 있습니다.

• 로그에 DNS 오류가 표시됨: 먼저 DNS 업스트림에 연결할 수 있는지 확인하세요. 암호화 DNS를 사용하는 경우 DNS 서버의 도메인도 초기 조회가 가능해야 하며, 관련 트래픽의 라우팅도 정상적으로 설정되어야 합니다.
• 로그에 반복적인 연결 시도나 DNS 조회가 표시됨: 노드 진입점 조회에 필요한 DNS 요청을 아직 연결되지 않은 동일한 프록시로 다시 보내도록 설정하지 않았는지 확인하세요.
• 브라우저에서만 문제가 발생함: 브라우저의 ‘보안 DNS’ 또는 사용자 지정 DNS 설정을 확인하세요. 잠시 시스템 DNS를 사용하도록 되돌린 다음 같은 URL에 다시 접속해 비교합니다.
• Fake-IP 주소가 반환됨: 설정에서 Fake-IP 모드를 사용하는 경우 일반적인 설정 범위에 속하는 198.18.0.0/16 주소가 표시되더라도 DNS 오류라고 단정할 수 없습니다. 주소 매핑과 트래픽 전달 경로를 계속 확인하세요.

mihomo 설정의 nameserver와 proxy-server-nameserver는 용도가 다릅니다. 후자는 프록시 노드 도메인을 조회할 때 사용합니다. 구독이나 오버라이드 기능이 설정을 관리한다면 먼저 백업을 만들고 최종 적용 내용을 확인한 뒤 해당 항목을 수정하세요. DNS 설정 전체를 무작정 붙여 넣으면 조회 방식, 라우팅 동작, 규칙 일치 조건이 한꺼번에 바뀔 수 있습니다.

6. 노드 자체 확인: 진입점 연결부터 프로토콜 핸드셰이크까지

앞선 로컬 확인을 마친 다음 원격 노드를 점검하세요. 노드 하나를 고정해 기존 네트워크와 휴대폰 핫스팟에서 각각 테스트하고, 이어서 네트워크를 고정한 채 진입점이 다른 노드로 바꿔 보세요. 이름이 다른 노드라도 같은 서버를 사용할 수 있으므로 지역 이름만 볼 것이 아니라 서버 주소를 기준으로 비교해야 합니다.

오류 발생 단계에 따라 로그 확인

TCP 진입점을 사용하는 노드는 Windows PowerShell에서 실제 서버 포트에 연결할 수 있는지 확인할 수 있습니다. 아래는 명령 형식의 예시이며, 도메인은 예약된 예시 도메인입니다. 실행 결과를 실제 노드 상태로 간주해서는 안 됩니다.

Test-NetConnection -ComputerName node.example.com -Port 443

설정에 있는 실제 주소와 포트로 바꾸고, 사용할 권한이 있는 서비스만 확인하세요. TcpTestSucceeded가 true여도 TCP 연결만 성공했다는 뜻입니다. 비밀번호, TLS, WebSocket 경로 또는 전체 프록시 프로토콜이 올바르다는 의미는 아닙니다. Hysteria2, TUIC처럼 UDP 전송을 사용하는 노드는 TCP 테스트 결과로 사용 가능 여부를 판단할 수 없습니다.

TCP 연결은 되지만 프로토콜 핸드셰이크에 실패한다면 서비스 제공업체에서 설정을 다시 받아 서버 이름, 인증 정보, 전송 매개변수를 확인하세요. 인증서 오류는 시스템 시간, 인증서 체인 또는 서버 이름 설정을 바로잡아 해결해야 합니다. 인증서 검증을 건너뛰는 방식은 장기적인 해결책으로 사용하지 마세요.

7. 복구 확인: 결과를 기록한 뒤 평소 사용 설정으로 되돌리기

노드가 복구되면 평소 사용하는 규칙 모드로 돌아가고, 실제로 필요한 시스템 프록시 또는 TUN 전달 방식만 다시 켜세요. 직접 연결할 사이트, 프록시가 필요한 사이트, 자주 사용하는 앱을 차례로 확인하고 연결 기록에서 출구 정책을 점검합니다. 전역 모드에서 접속된다는 사실은 해당 프록시 경로가 작동했다는 뜻일 뿐입니다. 규칙 모드의 분기 동작은 별도로 확인해야 합니다.

1. 환경 기록: 운영체제, FlClash 버전, 코어 버전, 오류가 발생한 날짜와 시간을 기록하세요. 버전 정보는 클라이언트에 실제로 표시된 값을 기준으로 합니다.
2. 비교 결과 기록: 기존 Wi-Fi와 핫스팟에서 차이가 있는지, 같은 노드가 다른 기기에서는 작동하는지, 다른 진입점은 정상인지 기록하세요.
3. 연결 경로 기록: 시스템 프록시와 TUN 중 사용한 방식, 실제 수신 포트, 출구 모드, 요청에 적용된 정책 그룹을 기록하세요.
4. 오류 기록 저장: 이번 문제를 재현한 로그 구간만 캡처하고 인증 정보, 구독 링크, 불필요한 접속 기록은 가리세요.

모든 노드가 특정 네트워크에서만 실패한다면 해당 네트워크의 DNS와 외부 연결 제한을 우선 확인하세요. 특정 노드가 여러 네트워크와 기기에서 모두 실패한다면 진입점 정보와 로그를 서비스 제공업체에 전달해 확인을 요청해야 합니다. 계층별로 원인을 파악한 다음 설정을 바꿔야 원인과 결과를 명확히 추적할 수 있습니다. 트래픽 전달과 분기 방식은 프로토콜 자세히 알아보기를 참고하세요.