첫 연결 확인 기준: 트래픽 유입·규칙 일치·출구
구독을 성공적으로 불러왔다는 사실은 클라이언트가 설정을 가져왔다는 뜻일 뿐, 브라우저나 명령줄, 게임이 프록시를 사용한다는 증거는 아닙니다. 노드 옆에 지연 시간이 표시되어도 지정된 테스트 요청에서 결과를 얻었다는 의미에 그칩니다. 제대로 확인하려면 앱의 트래픽 유입부터 규칙 판단, 노드 연결, 대상 서버 응답까지 이어서 살펴봐야 합니다.
클라이언트는 구독, 켜기·끄기, 화면을 관리하고, Clash나 Clash Meta(mihomo) 같은 코어는 포트를 열어 두고 규칙을 적용해 연결을 수립합니다. 클라이언트마다 메뉴 이름과 기본 포트가 다를 수 있습니다. 아래에서는 화면의 ‘설정’, ‘프록시’, ‘연결’, ‘로그’ 등의 기능을 기준으로 설명하며, 특정 클라이언트의 화면 구성을 표준으로 간주하지 않습니다.
- 설정이 적용됨: 현재 설정이 활성화되어 있고, 코어에서 파싱 오류가 보고되지 않습니다.
- 트래픽이 유입됨: 새로 보낸 테스트 요청이 클라이언트의 연결 목록이나 코어 로그에 표시됩니다.
- 정책이 예상대로 적용됨: 요청에 일치한 규칙이 프록시 정책 그룹을 가리키고, 최종 연결 경로에 선택한 노드가 포함됩니다.
- 응답을 확인할 수 있음: 대상 요청이 성공하고, 프록시 출구와 해당 직접 연결 기준을 비교할 수 있습니다.
구독을 불러온 뒤 현재 설정과 정책 그룹 확인하기
설정이 실제로 활성화되어 있는지 확인
‘설정’ 페이지에서 방금 불러온 설정을 찾아 선택되어 있는지 확인하세요. 목록에 보이는 것만으로는 충분하지 않습니다. 그런 다음 ‘로그’ 페이지에서 YAML 파싱 오류, 존재하지 않는 정책 이름, 포트 열기 실패 등이 있는지 살펴보세요. 구독 업데이트에 실패해도 일부 클라이언트는 마지막으로 정상 적용된 설정을 계속 사용합니다. 업데이트 시간과 노드 목록도 함께 확인하세요.
- 노드가 0개로 표시됨: 시스템 프록시 문제로 단정하지 말고 구독을 가져온 결과부터 확인하세요.
- 정책 이름이 없다는 알림이 표시됨: 규칙, 정책 그룹, 노드 제공자 참조가 서로 일치하는지 확인하세요.
- 주소가 사용 중이라는 알림이 표시됨: 다른 클라이언트가 로컬 프록시 포트를 사용하고 있는지 확인하세요.
- 노드는 표시되지만 모두 실패함: 구독 유효 기간, 네트워크 연결 상태, 코어의 프로토콜 지원 여부를 추가로 확인하세요.
정책 그룹을 따라가 실제 노드 선택하기
‘프록시’ 페이지에서 먼저 ‘규칙’ 모드를 선택한 다음, 규칙에서 실제로 참조하는 정책 그룹을 찾으세요. 예를 들어 설정 규칙이 ‘웹 프록시’를 가리키고 이 그룹에서 ‘수동 선택’을 골랐다면, ‘수동 선택’을 펼쳐 실제 노드를 지정해야 합니다. 관련 없는 다른 정책 그룹에서 노드를 선택해도 해당 규칙의 출구는 바뀌지 않습니다.
select 유형은 수동 선택에 사용합니다. url-test는 일반적으로 상태 확인 결과에 따라 자동으로 노드를 선택하고, fallback은 순서대로 사용 가능한 항목을 선택합니다. load-balance는 연결마다 서로 다른 출구를 할당할 수 있습니다. 처음 문제를 확인할 때는 기존 수동 선택 그룹에서 노드 하나를 고정해 자동 전환으로 인한 변수를 줄이세요.
그룹에서 현재 DIRECT를 선택했다면 해당 연결은 직접 연결됩니다. REJECT를 선택했다면 연결이 거부됩니다. 정책 그룹 이름이 ‘프록시’라고 해서 내부에서 반드시 프록시 노드를 선택한 것은 아닙니다. 현재 선택된 항목을 확인해야 합니다.
노드 지연 시간 테스트: 숫자의 의미
‘프록시’ 페이지에서 노드 지연 시간을 테스트하면, 일반적으로 코어가 테스트 대상 노드를 거쳐 지정된 URL에 요청을 보내고 걸린 시간을 기록합니다. 운영체제의 ICMP ping이나 다운로드 속도 테스트와는 다릅니다. 테스트 URL, 시간 초과 기준, DNS 상태, TLS 핸드셰이크, 연결 재사용 여부가 결과에 영향을 줄 수 있습니다.
| 표시 결과 | 알 수 있는 내용 | 추가 확인 사항 |
|---|---|---|
| 밀리초 값이 표시됨 | 이번 테스트에서 해당 노드를 통해 지정한 URL의 응답을 받음 | 실제 대상 사이트 이용 가능 여부와 서비스 요청의 안정성 |
| Timeout | 제한 시간 안에 이번 테스트가 완료되지 않음 | 노드, 테스트 주소, DNS, 네트워크 경로 중 어느 부분에 문제가 있는지 |
| 값이 크게 달라짐 | 반복 테스트마다 걸리는 시간이 다름 | 혼잡, 패킷 손실, 자동 노드 전환 여부 |
| 값이 표시되지 않음 | 아직 테스트하지 않았거나 화면에 결과가 표시되지 않았을 수 있음 | 코어 실행 상태와 테스트 오류 로그 |
한 번의 순위만 비교하지 말고 같은 조건으로 다시 테스트하기
- 테스트 URL을 하나로 고정하고, 결과에 영향을 주지 않도록 후보 노드 2~3개를 차례로 테스트하세요.
- 후보 노드마다 약 5초 간격으로 3회씩 테스트하고 성공 횟수와 편차를 기록하세요.
- 같은 네트워크 환경을 유지하세요. 테스트 도중 Wi-Fi, 모바일 네트워크, 유선 연결을 전환하지 마세요.
- 노드를 선택한 뒤 실제로 이용하려는 사이트나 서비스를 열어 새 연결과 응답을 확인하세요.
예를 들어 한 노드의 테스트 결과가 85 / 92 / 88 ms이고 다른 노드가 48 ms / Timeout / 410 ms라면, 전자가 안정성을 추가로 확인하기에 더 적합합니다. 이 숫자는 판단 방법을 설명하기 위한 예시이며 본 사이트에서 측정한 값이 아닙니다. 지연 시간이 짧은 노드도 출구 혼잡, 대상 사이트 제한, 대역폭 한도의 영향을 받을 수 있으므로 다운로드 속도를 보장하지는 않습니다.
트래픽 유입 확인: 시스템 프록시와 명시적 프록시 테스트
브라우저 테스트는 시스템 프록시부터 사용
클라이언트에서 ‘시스템 프록시’를 켠 다음 시스템 프록시 설정을 따르는 브라우저로 새 페이지를 여세요. 시스템 설정을 덮어쓸 수 있으므로 브라우저의 별도 프록시 확장 프로그램은 잠시 사용 중지하세요. 클라이언트의 ‘연결’ 페이지를 열고 새 요청을 보낸 뒤 해당 도메인, 대상 포트, 정책 경로가 표시되는지 확인하세요.
시스템 프록시는 시스템 전체 트래픽을 가로채지 않습니다. 일부 명령줄 도구, 게임, 앱은 시스템 프록시 설정을 무시합니다. 브라우저는 되지만 터미널에서 연결되지 않는다고 해서 노드가 고장 났다고 단정할 수 없습니다. 도구 자체의 프록시 옵션을 사용하거나, 필요한 경우 TUN을 설정하세요.
curl에서 로컬 포트를 직접 지정하기
아래 예시는 현재 실행 중인 설정의 HTTP 또는 혼합 프록시 포트가 7890이라고 가정합니다. 명령을 실행하기 전에 클라이언트의 포트 설정에서 실제 값을 확인하세요. 예시를 그대로 사용하려고 구독 설정 전체를 덮어쓰지 마세요. 혼합 포트는 HTTP와 SOCKS 프록시 연결을 모두 받을 수 있지만, SOCKS 전용 포트는 아래의 HTTP 프록시 방식에 바로 사용할 수 없습니다.
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/Windows PowerShell에서는 curl.exe를 사용하세요. 이전 환경에서 같은 이름의 별칭이 매개변수 해석을 바꾸는 일을 피할 수 있습니다. 200 Connection established가 표시되면 로컬 프록시가 HTTPS 터널 요청을 수락했다는 뜻입니다. 대상 사이트의 응답이나 최종 오류도 계속 확인하세요. 대상 사이트에서 301, 403 등의 상태를 반환해도 프록시 연결 실패를 의미하지는 않습니다.
로컬 포트에서 SOCKS5를 지원한다면 다음 방식으로 대상 도메인 요청을 SOCKS를 통해 프록시 측에 전달할 수 있습니다. curl이 로컬에서 대상 도메인을 먼저 조회하지 않습니다.
curl --proxy socks5h://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/규칙 일치와 출구 IP로 프록시 작동 확인하기
모드 스위치보다 연결 상세 정보가 더 확실함
‘연결’ 페이지에서 테스트 도메인을 필터링하고 대상 주소, 일치한 규칙, 연결 경로를 확인하세요. 클라이언트마다 표시하는 항목은 조금씩 다르지만 확인할 점은 같습니다. 요청이 코어에 들어왔는지, 어떤 규칙이 정책을 결정했는지, 정책 그룹이 최종적으로 어떤 출구를 선택했는지 살펴보세요. 트래픽 카운터가 증가하는 것만으로는 백그라운드 업데이트나 다른 앱의 연결일 수 있어 대상 요청을 확인한 것으로 볼 수 없습니다.
- 도메인 규칙과 일치함: 규칙 대상이 예상한 정책 그룹인지 확인하세요.
- 기본 규칙에 해당함: 마지막
MATCH가 프록시와 직접 연결 중 어디를 가리키는지 확인하세요. - 정책 경로에 DIRECT가 포함됨: 직접 연결된 것입니다. 시스템 프록시가 켜져 있어도 결과는 바뀌지 않습니다.
- 전환 후에도 이전 노드가 표시됨: 기존 연결이 이전 경로를 계속 사용할 수 있습니다. 연결을 새로 만든 뒤 다시 확인하세요.
규칙은 일반적으로 순서대로 적용되며, 먼저 일치한 규칙이 처리 방식을 결정합니다. 문제를 확인할 때 마지막 기본 규칙만 살펴보지 마세요. 앞쪽의 도메인 규칙, IP 규칙, 규칙 집합이 이미 요청을 처리했을 수 있습니다. 사용자 지정 규칙과 구독 업데이트 후의 유지 방법은 사용 설명서의 사용자 지정 규칙 안내를 참조하세요.
직접 연결 기준을 만든 뒤 프록시 출구 조회하기
먼저 TUN과 시스템 프록시를 끄고 다른 VPN이나 프록시 도구를 일시 중지한 다음, 아래 명령으로 현재 네트워크의 공인 IPv4 주소를 조회할 수 있습니다. 이 조회는 제3자 IP 조회 서비스에 요청을 보내므로 해당 서비스에서 요청 출처를 확인할 수 있습니다. 이 점을 감수할 수 있을 때만 사용하세요.
curl -4 --noproxy "*" --connect-timeout 10 --max-time 20 https://api.ipify.org그런 다음 TUN은 끈 상태로 유지하고 로컬 프록시를 시작한 뒤, 명시적 프록시 옵션을 사용해 다시 조회하세요. 조회 도메인이 선택한 노드를 거치도록 규칙이 설정되어 있는지도 확인하세요.
curl -4 --proxy http://127.0.0.1:7890 --noproxy "" --connect-timeout 10 --max-time 20 https://api.ipify.org--noproxy "*"는 curl이 앱 계층의 프록시 설정을 건너뛰게 할 뿐, 계속 실행 중인 TUN이나 다른 투명 프록시를 우회하지 못합니다. 따라서 기준을 측정하기 전에 이런 트래픽 가로채기 기능을 끄는 것이 중요합니다. 두 주소가 다르고 두 번째 연결 경로에 선택한 노드가 포함된다면 프록시 출구가 작동한다는 유력한 증거입니다. 주소가 같다면 규칙에 따른 직접 연결, 조회 캐시, 프록시와 로컬 네트워크의 공통 출구 등을 추가로 확인하세요.
IP 주소의 지역 정보는 데이터베이스의 추정치이며 오래된 정보일 수 있습니다. IPv4 조회 결과만으로 IPv6 및 모든 UDP 트래픽의 경로를 알 수 없고, DNS 누출이 없다는 점도 증명할 수 없습니다. 확인 범위를 구체적인 앱, 주소 체계, 프로토콜로 한정해 한 번의 성공을 ‘모든 네트워크가 프록시를 사용한다’고 확대 해석하지 마세요.
TUN과 자주 발생하는 실패: 계층별로 원인 찾기
시스템 프록시를 따르지 않는 앱의 트래픽까지 처리해야 할 때 TUN 사용을 고려하세요. TUN은 가상 네트워크 어댑터와 라우팅을 통해 트래픽을 전달하며, 일반적으로 서비스 권한, 라우팅 설정, DNS 처리가 필요합니다. 스위치를 켠 것은 활성화를 요청했다는 의미일 뿐입니다. 가상 네트워크 어댑터와 경로가 설정되었는지, 대상 앱에서 새 연결이 발생하는지 확인해야 합니다. mihomo 기반 클라이언트마다 기본 설정이 다를 수 있으므로 화면이 비슷하다고 동작도 같다고 가정하지 마세요.
| 증상 | 우선 확인할 항목 | 다음 조치 |
|---|---|---|
| 로컬 연결이 거부됨 | 코어 실행 상태, 수신 포트 | 127.0.0.1과 실제 포트를 확인하고 포트 열기 실패 로그를 살펴보세요. |
| 지연 시간 테스트는 성공했지만 브라우저는 연결되지 않음 | 시스템 프록시, 브라우저의 별도 프록시, 대상 사이트 제한 | 같은 대상을 명시적 프록시로 테스트한 뒤 연결 기록을 확인하세요. |
| 브라우저는 되지만 명령줄은 연결되지 않음 | 도구가 시스템 프록시를 따르는지 여부 | 먼저 노드 설정을 바꾸지 말고 도구의 프록시 옵션을 사용하세요. |
| 모든 노드에서 시간 초과 | 구독 상태, 테스트 주소, 네트워크 경로 | 구체적인 오류를 확인하고 노드 몇 개만 차례로 테스트하세요. |
| TUN을 켠 뒤 도메인을 조회할 수 없음 | DNS 설정과 다른 VPN의 충돌 여부 | 충돌하는 도구를 끄고 시스템 프록시 기준 상태로 되돌린 뒤 항목별로 확인하세요. |
| 웹페이지는 되지만 UDP 앱은 작동하지 않음 | 노드, 프로토콜, 트래픽 처리 경로의 UDP 지원 여부 | 실제 UDP 앱에서 별도로 확인하고 웹페이지 테스트로 대신하지 마세요. |
로그 상세도는 필요한 동안만 높이기
먼저 일반 로그 수준에서 문제를 한 번 재현하세요. 정보가 부족할 때만 잠시 debug로 높이고, 실패 시간과 대상 도메인을 기록한 뒤 원래 수준으로 되돌리세요. 오류마다 발생 단계가 다릅니다. 연결 거부는 로컬 포트 수신 문제일 가능성이 높고, 도메인 조회 실패는 DNS 문제일 가능성이 큽니다. 핸드셰이크 실패는 노드 매개변수, 인증서, 서버와 관련될 수 있으며, 시간 초과는 발생 위치를 함께 살펴봐야 합니다.
스크린샷이나 로그를 공유하기 전에 구독 링크, 인증 정보, 제어 인터페이스 키, 개인 접속 기록을 가리세요. 구독 링크에는 접속 정보가 포함되는 경우가 많으므로 문제 해결을 위해 공개 댓글에 그대로 올리지 마세요. 일반적인 시스템 문제는 Clash 자주 묻는 질문에서도 확인할 수 있습니다.
첫 연결 후 확인 목록
위 절차를 마친 뒤에는 한 번의 지연 시간 순위를 기억하는 것보다 반복해서 사용할 수 있는 테스트 방법을 남겨 두는 편이 유용합니다. 네트워크, 노드, 규칙이 바뀌면 같은 대상으로 다시 확인할 수 있어 매번 클라이언트를 재설치할 필요가 없습니다.
- 현재 활성화된 설정, 코어 이름, 실제 로컬 프록시 포트를 기록하세요.
- 사용 가능한 노드 하나를 고정하고 같은 조건으로 지연 시간을 최소 3회 확인하세요.
- 명시적 프록시 요청으로 로컬 진입점이 작동하는지 확인하고 대상 서버의 응답을 확인하세요.
- 전체 트래픽만 보지 말고 연결 상세 정보에서 규칙, 정책 그룹, 최종 노드를 확인하세요.
- 직접 연결 기준과 프록시 출구를 비교하고 IPv4와 IPv6 중 어느 쪽을 테스트했는지 기록하세요.
- 필요에 따라 자동 선택을 복원하거나 TUN을 켠 뒤 실제 앱에서 다시 확인하세요.
프록시가 작동하는지 판단할 때는 ‘대상 요청이 코어에 들어왔는가, 규칙이 올바른 정책을 가리키는가, 최종 출구가 예상과 일치하는가’를 중심으로 확인하세요. 지연 시간은 후보 노드를 고르는 데, 출구 조회는 경로를 확인하는 데, 연결 로그는 두 결과를 연결하는 데 유용합니다. 이 세 가지 증거는 서로 대체할 수 없습니다.