FlClash 노드 연결 시간 초과·연결 안 됨 해결법: 구독, 시간 동기화, DNS 순서대로 점검
FlClash 노드 연결 시간 초과 원인을 구독과 설정, 시스템 시간, 포트·방화벽, DNS 순으로 확인하세요. 각 단계별 증상과 해결 방법을 정리했습니다.
1. 노드 테스트 시간 초과와 실제 접속 실패 구분하기
FlClash 노드 테스트에 실패했다고 해서 모든 웹페이지에 접속할 수 없는 것은 아닙니다. 테스트는 지정된 검사 주소에 연결합니다. 해당 주소가 차단되거나 비정상 응답을 반환하거나 응답이 제한 시간을 넘기면 시간 초과로 표시될 수 있습니다. 반대로 테스트에 성공해도 그 시점의 탐색만 가능하다는 뜻이며, 모든 도메인이나 UDP 요청, 앱 연결까지 정상이라는 의미는 아닙니다.
문제 해결을 시작하기 전에 현재 상태를 기록해 두세요. FlClash 버전, 운영체제 버전, 현재 설정 이름, 아웃바운드 모드, 실패가 발생한 시간을 적습니다. 그런 다음 같은 URL과 같은 접속 방식으로 다시 테스트하고, 설정은 한 번에 하나씩만 변경하세요. 버전에 따라 메뉴 위치가 다를 수 있으므로 아래 안내에서는 설정 항목 이름과 확인 가능한 시스템 조작을 기준으로 설명합니다. 예시 포트가 클라이언트의 기본값이라고 가정하지 마세요.
| 증상 | 먼저 확인할 항목 | 판단 기준 |
|---|---|---|
| 구독 업데이트 오류, 목록이 비어 있음 | 구독 URL, 응답 내용, 설정 파싱 | 아직 사용할 수 있는 노드 설정이 없음 |
| 노드 하나만 실패 | 노드 서버 상태, 프로토콜 매개변수 | 같은 네트워크에서 다른 노드로 같은 URL에 접속 가능 |
| 모든 노드 실패 | 로컬 네트워크, 시간, 코어 실행 상태 | 서로 다른 여러 노드에서 실패 |
| 테스트는 성공했지만 브라우저에서 접속할 수 없음 | 시스템 프록시, 규칙, DNS | 탐색 요청과 브라우저 트래픽의 경로가 다를 수 있음 |
| 브라우저는 되지만 특정 앱은 안 됨 | 앱의 프록시 지원, UDP, TUN | 시스템 프록시만으로는 보통 모든 앱 트래픽을 처리할 수 없음 |
여러 프로그램이 동시에 시스템 프록시나 라우팅을 변경하지 않도록 다른 프록시 클라이언트와 VPN을 잠시 종료하세요. 회사 네트워크에 접속해야 하는 경우 관리되는 보안 소프트웨어를 임의로 비활성화하지 말고, 허용된 접속 방법을 관리자에게 먼저 확인하세요.
2. 구독 업데이트와 현재 설정 확인하기
업데이트 성공 후 실제 사용 중인 설정 확인
- FlClash의 설정 목록에서 사용할 구독을 찾아 업데이트하고, 결과와 업데이트 시간을 기록하세요.
- 현재 선택된 설정이 방금 업데이트한 설정인지 확인하세요. 목록에 새 설정이 보인다고 해서 코어가 해당 설정으로 전환된 것은 아닙니다.
- 프록시 화면에 예상한 정책 그룹과 노드가 표시되는지 확인하세요. 정책 그룹이 비어 있다면 DNS를 바로 수정하지 말고 먼저 설정 로드 오류를 확인하세요.
- 현재 규칙에서 참조하는 정책 그룹에서 노드를 직접 선택한 뒤 같은 URL로 테스트하세요. 자동 선택 그룹은 테스트 중 아웃바운드 노드를 다시 선택할 수 있어 결과를 비교하기 어렵습니다.
구독 다운로드 실패와 노드 연결 실패는 서로 다른 과정에서 발생합니다. 전자는 클라이언트가 설정을 가져오는 과정이고, 후자는 mihomo 코어가 설정에 따라 서버에 연결하는 과정입니다. 이전 설정은 계속 작동할 수 있으므로 구독 업데이트에 실패해도 웹페이지가 열리는 상황은 모순이 아닙니다.
오류 응답에 따라 처리하고 같은 URL을 반복해서 가져오지 마세요
- HTTP 401 또는 403: 구독이 만료됐는지, 링크가 재발급 또는 초기화됐는지, 서버에서 접근을 제한하는지 확인하세요. 게이트웨이에서 반환한 상태 코드일 수도 있으므로 응답 출처도 함께 확인해야 합니다.
- HTTP 200이지만 설정 파싱 실패: 로그인 페이지나 인증 페이지, 호환되지 않는 내용이 반환됐을 수 있습니다. 상태 코드가 성공이라고 해서 유효한 설정이 반환된 것은 아닙니다.
- 도메인 확인 실패 또는 연결 시간 초과: 현재 네트워크에서 구독 도메인에 접속할 수 있는지 먼저 확인하세요. 구독 업데이트에 프록시를 사용하는지는 클라이언트 버전과 관련 설정에 따라 다르므로 브라우저 접속 결과만으로 판단할 수 없습니다.
- 업데이트 후 일부 노드가 사라짐: 구독 플랜 상태와 서비스 제공자의 변경 사항을 확인한 다음, 설정에서 참조하는 정책 그룹을 점검하세요. 더는 사용할 수 없는 항목을 선택하지 않도록 주의해야 합니다.
3. 기본 네트워크와 시스템 시간 확인하기
FlClash의 시스템 프록시와 TUN을 끈 다음 일반적인 직접 연결로 웹페이지에 접속할 수 있는지 확인하세요. 네트워크에서 포털 인증이 필요하다면 먼저 Wi-Fi 로그인을 완료하세요. 설정과 테스트 URL은 그대로 두고 컴퓨터를 휴대폰 핫스팟에 연결해 볼 수도 있습니다. 같은 노드가 특정 네트워크에서만 실패한다면 클라이언트를 다시 설치하기보다 해당 네트워크의 외부 연결 제한, 라우팅 또는 UDP 지원 여부를 먼저 확인하세요.
시간 오차는 TLS 및 일부 프로토콜 인증에 영향을 줍니다
시스템 날짜, 표시되는 시간대, 실제 시간을 각각 확인하세요. 시간대 표시가 다르다고 반드시 인증에 실패하는 것은 아니지만, 시스템 시계가 실제 시간과 크게 어긋나면 인증서가 아직 유효하지 않거나 만료된 것으로 판정될 수 있습니다. 시간 검증을 사용하는 일부 프로토콜도 연결을 거부할 수 있습니다.
- Windows 11: 「설정」→「시간 및 언어」→「날짜 및 시간」에서 「자동으로 시간 설정」을 켠 다음 「지금 동기화」를 실행하세요.
- Android: 일반적으로 「설정」→「시스템」→「날짜 및 시간」에서 자동 설정을 켭니다. 제조사에 따라 「추가 설정」에 있을 수 있습니다.
- macOS: 「시스템 설정」→「일반」→「날짜 및 시간」에서 날짜와 시간 자동 설정이 켜져 있는지 확인하세요.
시간을 동기화한 뒤 연결을 다시 설정하고 인증서 오류가 사라졌는지 확인하세요. 시간이 정확한데도 TLS 오류가 계속되면 서버 도메인, 인증서, 설정의 TLS 매개변수를 추가로 점검하세요. 인증서 검증 건너뛰기를 일반적인 해결책으로 사용하지 마세요. 연결 인증이 약해질 뿐 아니라 서버에 연결할 수 없는 문제도 해결되지 않습니다.
4. 혼합 포트, 코어 실행 상태, 방화벽 확인하기
시스템 프록시는 프록시를 지원하는 앱이 로컬 리슨 포트를 사용하도록 설정합니다. mihomo가 실행되지 않았거나 다른 프로그램이 해당 포트를 사용 중이면, 브라우저에 프록시가 설정된 것으로 표시되어도 FlClash를 통해 연결할 수 없습니다. 먼저 클라이언트 로그에서 address already in use, bind 또는 설정 로드 실패 메시지가 있는지 확인하세요.
실제 혼합 포트로 명시적 프록시 테스트하기
FlClash 설정에서 「혼합 포트」를 찾아 값을 확인하세요. 아래 예시는 모두 7890을 사용합니다. 클라이언트에 표시된 포트도 7890일 때만 그대로 실행하세요. 테스트 URL은 실제로 접속이 필요하고 접근이 허용된 HTTPS 사이트로 바꿔도 됩니다.
# Windows PowerShell: 7890 포트를 리슨 중인 프로세스 확인
Get-NetTCPConnection -LocalPort 7890 -State Listen |
Select-Object LocalAddress, LocalPort, OwningProcess
# Windows: 로컬 HTTP 프록시를 지정해 요청 보내기
curl.exe -I --proxy http://127.0.0.1:7890 --connect-timeout 8 --max-time 20 https://example.com/
# macOS / Linux: 리슨 포트 확인 후 같은 요청 실행
lsof -nP -iTCP:7890 -sTCP:LISTEN
curl -I --proxy http://127.0.0.1:7890 --connect-timeout 8 --max-time 20 https://example.com/
여기서 8초는 연결 단계의 제한 시간이고, 20초는 요청 전체의 제한 시간입니다. 노드 품질 기준이 아닙니다. curl -I는 HEAD 요청을 보냅니다. 일부 웹사이트는 403 또는 405를 반환할 수 있습니다. HTTP 응답을 받았다면 서버 응답 단계까지 연결이 진행된 것이지만, TLS 연결 완료 여부와 클라이언트 연결 기록도 함께 확인해야 합니다.
- 즉시 연결 거부 응답: 로컬 포트가 올바른지, 코어가 실행 중인지 확인하세요. 원격 노드만 바꿔서는 보통 해결되지 않습니다.
- 다른 프로세스가 포트를 리슨 중: 프로세스 ID로 어떤 프로그램인지 확인한 뒤 충돌하는 프로그램을 정상 종료하거나 FlClash 포트를 변경하고 앱의 프록시 설정도 함께 수정하세요. 정체를 알 수 없는 시스템 프로세스를 바로 종료하지 마세요.
- 로컬 프록시 연결은 성공한 뒤 시간 초과: 원격 연결, 규칙, DNS를 추가로 확인하고 같은 시간대의 로그를 살펴보세요.
프로그램과 네트워크 범위에 맞춰 방화벽 허용하기
방화벽이나 엔드포인트 보안 소프트웨어가 코어의 아웃바운드 연결을 제한할 수 있습니다. 차단 기록을 확인한 뒤 실제 실행 파일을 허용하세요. 업그레이드 후 파일 위치가 바뀌었다면 기존 규칙이 여전히 유효한지도 확인해야 합니다. 로컬 프록시 테스트에는 보통 「LAN 연결 허용」을 켜거나 공용 네트워크의 인바운드 포트를 열 필요가 없습니다. 방화벽 전체를 끄는 방법을 장기적인 해결책으로 삼지 마세요.
5. 로그를 확인해 DNS 조회 실패와 원격 연결 시간 초과 구분하기
도메인 문제에서는 최소한 두 대상을 구분해야 합니다. 프록시 서버의 도메인과 최종 접속 사이트의 도메인입니다. 서버 도메인을 확인할 수 없으면 프록시 서버에 연결하기도 전에 실패합니다. 사이트 도메인의 조회 경로는 규칙, 아웃바운드 프로토콜, DNS 설정에 따라 달라집니다. DNS 오류가 보이면 먼저 어느 도메인에서 오류가 발생했는지 확인한 뒤 해당 단계의 설정을 수정하세요.
시스템 DNS 조회는 시스템 DNS 경로만 확인합니다
# 예시 사이트의 시스템 DNS 조회 결과 확인
nslookup example.com
시스템 조회도 실패한다면 네트워크와 시스템 DNS가 정상인지 먼저 확인하세요. 조회는 성공하지만 FlClash 로그에 no such host 또는 조회 시간 초과가 계속 표시되면 클라이언트 코어가 사용하는 DNS 경로를 별도로 점검해야 합니다. 설정의 nameserver, proxy-server-nameserver, direct-nameserver는 각각 용도가 다릅니다. 시스템 조회 성공만으로 모든 경로가 정상이라고 판단할 수는 없습니다.
- 노드 서버 도메인 확인 실패: 프록시 서버 도메인을 조회하는 리졸버에 연결할 수 있는지 확인하세요. 리졸버 자체가 아직 연결되지 않은 프록시를 거쳐야만 접속 가능한 상황은 피해야 합니다.
- DNS-over-HTTPS 요청 시간 초과: DNS 서비스 도메인의 초기 조회, HTTPS 연결, 라우팅이 정상인지 확인하세요. 모든 리졸버를 같은 주소로 바꾸면 장애 범위가 커질 수 있습니다.
198.18.0.0/15범위의 주소가 표시됨: Fake-IP 모드에서는 예상된 매핑 결과일 수 있습니다. 주소 형식만 보고 조회 오류라고 단정하지 마세요.- 특정 웹사이트 하나만 이상함: 전체 설정을 바꾸기 전에 해당 도메인에 적용된 규칙, DNS 응답, 대상 서비스 상태를 확인하세요.
DNS를 변경한 뒤에는 클라이언트에서 제공하는 다시 불러오기 또는 코어 재시작 기능을 사용해 설정을 적용하고, 기존 연결을 끊은 다음 다시 테스트하세요. Windows의 ipconfig /flushdns는 시스템 DNS 캐시만 갱신하며 mihomo DNS 캐시나 기존 연결을 지우지는 않습니다. 한 번에 한 항목만 변경하고 원래 설정을 복구할 수 있도록 보관하세요.
6. 아웃바운드 모드, 규칙 적용, TUN 트래픽 처리 범위 확인하기
규칙 모드에서 실패하면 전역 모드로 범위 좁히기
규칙 모드는 위에서 아래 순서로 일치 여부를 확인하며, 처음으로 일치하는 규칙의 아웃바운드를 사용합니다. 브라우저 요청이 DIRECT 규칙에 걸리면 노드 테스트가 성공했더라도 해당 요청은 선택한 노드를 거치지 않을 수 있습니다. 클라이언트의 연결 기록에서 대상 도메인, 일치한 규칙, 최종 아웃바운드를 대조해 문제의 요청이 실제로 어떤 경로를 이용했는지 확인하세요.
- 같은 노드와 테스트 URL을 유지한 채 잠시 전역 모드로 전환하고, 전역 정책 그룹에서 해당 노드가 선택됐는지 확인하세요.
- 전역 모드에서는 되지만 규칙 모드에서는 실패한다면 해당 규칙이 잘못된 정책 그룹이나
DIRECT,REJECT를 지정하는지 확인하세요. - 두 모드 모두 실패한다면 규칙 순서만 바꾸지 말고 서버 연결과 DNS를 추가로 확인하세요.
- 테스트가 끝나면 원래 모드로 되돌리세요. 전역 모드는 비교 테스트용이며 모든 트래픽에 적합한 설정은 아닙니다.
시스템 프록시와 TUN은 서로 다른 문제를 해결합니다
프록시를 명시한 테스트는 성공했지만 특정 앱에서 접속할 수 없다면 해당 앱이 시스템 프록시를 따르는지 확인하세요. 일부 앱은 자체적으로 연결을 설정하거나 UDP를 사용하므로 시스템 프록시를 켜도 자동으로 클라이언트를 거치지 않습니다. TUN은 가상 네트워크 인터페이스를 통해 더 많은 트래픽을 처리할 수 있지만 라우팅, 권한, 제외 규칙의 영향을 받으며 모든 트래픽을 처리한다고 보장하지는 않습니다.
TUN을 켜기 전에 일반 프록시 연결이 작동하는지 먼저 확인하세요. 데스크톱 운영체제에서는 관리자 권한이나 서비스 지원이 필요할 수 있습니다. Android에서는 VPN 연결 권한을 허용해야 하며, 일반적으로 다른 VPN 기반 앱과 동시에 사용할 수 없습니다. TUN을 켠 뒤 기기 전체에서 인터넷이 끊기면 먼저 TUN을 꺼서 연결을 복구한 다음 가상 인터페이스, 라우팅, 다른 VPN과의 충돌을 확인하세요. 원인을 구분하기 어려워지므로 TUN, DNS, 규칙을 한꺼번에 변경하지 마세요.
7. 결과 정리: 노드를 바꾸거나 로그를 제출해야 할 때
위 항목을 확인한 뒤에는 단순히 “FlClash가 안 된다”가 아니라 문제 발생 단계를 구체적으로 좁힐 수 있어야 합니다. 특정 노드만 여러 네트워크에서 실패하고 다른 노드는 작동한다면 서비스 제공자에게 서버 상태와 인증 정보를 확인하세요. 같은 네트워크에서 모든 노드가 실패한다면 로컬 네트워크 제한부터 살펴보세요. 프록시를 명시한 연결은 되지만 시스템 프록시는 작동하지 않는다면 다른 프로그램이 시스템 설정을 덮어썼는지 확인하세요.
문제를 제출하기 전에 다음 6가지 정보를 준비하세요
- FlClash 버전, 운영체제 버전, 로그에 표시되는 mihomo 코어 버전
- 실패 시각과 시간대. 서버 기록과 대조하는 데 필요합니다.
- 구독 업데이트 성공 여부와 현재 설정의 로드 성공 여부
- 시스템 프록시 및 TUN 사용 여부, 실제 혼합 포트, 현재 아웃바운드 모드
- 같은 URL을 프록시 지정, 규칙 모드, 전역 모드에서 테스트한 결과
- 실패 전후의 짧은 로그. 구독 토큰, 계정 인증 정보, 공개하기 부적절한 주소는 가리세요.
초기 설정을 다시 확인하려면 입문 가이드를, 증상에 따라 계속 진단하려면 문제 해결 가이드를 참고하세요. 클라이언트를 업데이트하기 전에 현재 설정과 주요 옵션을 보관하세요. 업데이트 후 같은 테스트를 다시 해야 변화가 버전이나 설정에서 비롯됐는지 판단할 수 있습니다.