Clash 첫 연결 점검 가이드: 속도 테스트부터 프록시 작동 확인까지
설정을 불러온 뒤 노드를 선택하고 지연 시간을 측정한 다음 시스템 프록시를 켜세요. 연결 로그와 외부 IP를 확인해 트래픽이 프록시를 통과하는지 점검할 수 있습니다.
1. 구독을 불러온 뒤 설정이 활성화됐는지 확인
구독을 성공적으로 불러왔다는 것은 클라이언트가 설정 내용을 가져왔다는 뜻일 뿐입니다. 브라우저 연결이 프록시를 거치려면 설정 활성화, 프록시 그룹에서 노드 선택, 트래픽 연결을 마쳐야 합니다. 처음 연결할 때는 시스템 프록시로 브라우저 요청을 확인하고, 문제가 어느 단계에서 발생하는지 파악하기 쉽도록 TUN 모드는 일단 꺼 두세요.
클라이언트에 따라 설정 메뉴가 ‘설정’, ‘구독’ 또는 ‘Profiles’로 표시될 수 있습니다. 해당 화면에서 아래 네 가지를 확인하세요. ‘업데이트 성공’ 메시지만으로 판단해서는 안 됩니다.
- 현재 설정: 불러온 항목이 목록에 저장만 된 것이 아니라 선택되었거나 활성화되어 있는지 확인합니다.
- 업데이트 시간: 수동으로 한 번 업데이트해 인증 실패, 다운로드 시간 초과, 파싱 오류가 없는지 확인합니다.
- 코어 상태: Clash 또는 mihomo가 실행 중이고, 로그에 설정 로드 실패나 포트 충돌 등의 오류가 없는지 확인합니다.
- 프록시 그룹 구성: 노드나 불러온 노드 제공자가 표시되는지 확인합니다. 빈 그룹과 DIRECT만 있어서는 안 됩니다.
설정에서 지원하지 않는 필드라는 오류가 표시되면 먼저 구독에 필요한 코어를 확인하세요. Clash와 mihomo의 설정 지원 범위는 완전히 같지 않습니다. 시스템 프록시를 반복해서 켜고 꺼도 설정 문법이나 프로토콜 호환 문제는 해결되지 않으므로, 우선 코어가 설정을 정상적으로 불러오는지 확인해야 합니다.
2. 프록시 그룹에서 노드를 선택하고 지연 시간 테스트
클라이언트에서 ‘프록시’ 또는 ‘Proxies’ 화면을 열고 기본 프록시 그룹을 찾으세요. 그룹 이름은 구독 설정에 따라 ‘노드 선택’일 수도 있고 다른 이름일 수도 있습니다. 먼저 규칙이 실제로 어떤 그룹을 사용하는지 확인한 다음, 해당 그룹에서 노드를 선택하세요. 그룹 안에 다른 프록시 그룹이 중첩되어 있다면 최종 출구가 정해질 때까지 다음 단계도 확인해야 합니다.
지연 시간 수치로 알 수 있는 것
클라이언트의 지연 시간 테스트는 보통 노드를 통해 지정된 테스트 URL에 요청을 보내는 방식이며, 단순한 ICMP Ping과는 다릅니다. 결과는 테스트 주소, 시간 초과 설정, DNS, 당시 회선 상태에 따라 달라집니다. 현재 연결할 수 있는 노드를 추리는 데 유용하지만 다운로드 대역폭을 직접 보여 주거나 모든 웹사이트 접속을 보장하지는 않습니다.
- 먼저 노드 2~3개를 테스트하세요. 테스트 주소와 시간 초과 조건은 동일하게 맞추는 것이 좋습니다.
- 각 노드를 3회 연속 테스트해 안정성을 확인하세요. 한 번 나온 최저 수치만 보고 선택하지 마세요.
- 불필요한 트래픽을 줄이려면 대용량 파일 속도 테스트에 앞서 일반 웹페이지 접속부터 확인하세요.
예를 들어 한 회선의 측정값이 85, 92, 88ms이고 다른 회선은 45ms, 시간 초과, 310ms라면, 최저 지연 시간은 더 높더라도 결과 편차가 작은 첫 번째 회선이 첫 연결 확인에 더 적합합니다. 이는 결과를 판단하는 예시일 뿐, 특정 노드의 실제 측정 결과가 아닙니다.
시간 초과와 자동 선택 처리
특정 노드 하나만 시간 초과되면 같은 그룹의 다른 노드를 선택해 보세요. 모든 노드가 시간 초과되면 로컬 네트워크, 구독 유효 기간, 시스템 시간, 코어 오류를 확인해야 합니다. 테스트 주소 자체에 연결할 수 없어 여러 노드가 한꺼번에 시간 초과될 수도 있으므로 실제로 접속하려는 웹사이트에서도 확인하세요.
url-test 자동 테스트 그룹을 선택하면 테스트 결과에 따라 현재 출구 노드가 정해집니다. fallback 그룹은 일반적으로 사용 가능 여부와 설정 순서에 따라 노드를 선택하고, load-balance 그룹은 연결마다 다른 노드를 사용할 수 있습니다. 첫 연결 점검을 재현하기 쉽게 하려면 수동 선택 그룹에서 노드 하나를 고정해 테스트한 뒤 자동 정책으로 되돌리세요.
3. 규칙 모드에서 시스템 프록시 켜기
데스크톱 클라이언트의 첫 연결 확인에는 규칙 모드를 권장합니다. 설정의 rules를 위에서 아래로 적용하므로 요청이 프록시 그룹으로 전달될 수도 있고 DIRECT 또는 REJECT에 매칭될 수도 있습니다. 시스템 프록시는 시스템 프록시 설정을 따르는 앱의 요청을 로컬 수신 포트로 전달합니다. 두 기능의 역할이 다르므로 각각 확인해야 합니다.
| 모드 | 처리 방식 | 첫 점검에서의 용도 |
|---|---|---|
| 규칙 모드 | 규칙에 따라 직접 연결, 프록시 또는 차단을 선택 | 일상적인 트래픽 분기가 예상대로 작동하는지 확인 |
| 전역 모드 | 코어에 전달된 일반 프록시 요청을 전역 선택기로 전달 | 규칙의 영향을 잠시 분리할 때 사용합니다. 전역 정책을 올바르게 선택해야 합니다. |
| 직접 연결 모드 | 코어에 전달된 일반 요청을 직접 연결로 처리 | 프록시 노드의 출구를 확인하는 용도로는 적합하지 않음 |
‘전역 모드’라고 해서 시스템의 모든 트래픽을 가로채는 것은 아닙니다. 코어로 들어오지 않은 연결은 전역 모드로 바꿔도 자동으로 프록시를 거치지 않습니다. 브라우저 프록시 확장 프로그램, 앱 자체의 프록시 설정, 시스템 프록시가 서로 덮어쓸 수도 있으므로 문제를 살펴볼 때는 먼저 별도의 프록시 확장 프로그램을 끄세요.
로컬 주소와 수신 포트 확인
클라이언트 설정에서 HTTP 포트나 혼합 포트를 찾으세요. 127.0.0.1:7890은 흔히 쓰이는 예시일 뿐이며, 실제 값은 현재 설정을 기준으로 확인해야 합니다. mixed-port는 HTTP와 SOCKS 프록시 요청을 모두 받을 수 있습니다. external-controller는 제어 인터페이스이므로 브라우저 프록시 포트로 사용할 수 없습니다.
- Windows 11: ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’ → ‘수동 프록시 설정’에서 클라이언트가 입력한 주소와 포트를 확인합니다. 처음에는 클라이언트의 시스템 프록시 스위치를 사용하는 것이 좋습니다.
- macOS: ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 서비스 → ‘세부사항’ → ‘프록시’에서 현재 적용된 프록시 항목을 확인합니다. macOS 버전에 따라 메뉴 이름이 조금 다를 수 있습니다.
이 컴퓨터에서만 사용할 경우 ‘연결 성공’을 위해 LAN 접근 허용을 켜거나 제어 인터페이스를 외부에 개방할 필요는 없습니다. 수신 포트가 충돌하면 해당 포트를 사용하는 다른 프록시 프로그램을 먼저 종료한 뒤 현재 클라이언트를 다시 시작하세요.
4. 연결 로그에서 규칙과 실제 노드 확인
시스템 프록시를 켠 다음 클라이언트의 ‘연결’ 또는 ‘Connections’ 화면을 열고, 브라우저에서 새 탭을 열어 확인할 웹사이트에 접속하세요. 전체 트래픽 수치가 바뀌는지를 보는 대신 방금 발생한 요청을 찾는 것이 중요합니다. 일부 연결은 금방 종료되므로 로그 화면도 함께 확인하세요.
- 대상 확인: 도메인이나 대상 주소가 방금 방문한 웹사이트와 일치하는지 확인합니다.
- 매칭 규칙 확인: 도메인 규칙, 규칙 세트, 지역 규칙 또는 마지막의
MATCH중 무엇에 매칭됐는지 확인합니다. - 정책 경로 확인: DIRECT인지, 예상한 프록시 그룹과 최종 노드인지 확인합니다.
- 전송 상태 확인: 요청에서 송수신 데이터가 발생하는지, 연결 실패나 시간 초과가 반복되는지 확인합니다.
요청이 DIRECT에 매칭됐다면 코어에는 들어왔지만 직접 연결로 분기된 것입니다. 시스템 프록시가 작동하지 않았다는 뜻은 아닙니다. 반대로 관련 연결 기록이 전혀 없다면 앱이 시스템 프록시를 따르는지, 페이지가 캐시에서 로드됐는지, 클라이언트가 일부 연결을 숨기는지 확인하세요. mihomo 설정에서 로그 수준을 지정하거나 관련 기록을 숨겼을 수도 있으므로 화면이 비어 있다는 이유만으로 단정해서는 안 됩니다.
대상 요청은 보이지만 예상과 다른 노드를 사용한다면 프록시 그룹 중첩 여부, 부하 분산 사용 여부, 클라이언트가 이전 선택을 복원했는지 확인하세요. 규칙, DNS, TUN 설정을 한꺼번에 바꾸기보다 노드 하나를 임시로 고정하는 편이 원인을 찾기 쉽습니다.
5. 외부 IP를 비교해 프록시 작동 여부 확인
연결 로그는 ‘요청이 어떤 경로로 처리됐는지’를 보여 주고, 외부 IP는 ‘외부 서비스에 어떤 주소가 보이는지’를 확인하는 데 도움이 됩니다. 두 가지를 함께 확인하는 것이 더 확실합니다. 시스템 프록시와 TUN을 끈 상태에서 직접 연결의 외부 IP를 기록한 다음, 시스템 프록시를 켜고 노드를 고정한 뒤 같은 IP 조회 서비스로 다시 확인하세요. 테스트할 때 다른 VPN이 함께 실행 중이면 직접 연결 기준값도 다른 터널을 거칠 수 있으므로 주의하세요.
규칙 모드에서는 IP 조회 서비스 자체가 직접 연결로 설정되어 있을 수 있습니다. 외부 IP가 바뀌지 않았다면 먼저 해당 요청에 매칭된 규칙을 확인하세요. 규칙의 영향을 분리해야 한다면 잠시 전역 모드로 전환하고 전역 선택기를 대상 노드로 설정해 테스트한 뒤 규칙 모드로 되돌리세요.
명령줄로 로컬 프록시와 시스템 연결 구분하기
아래 예시는 혼합 포트 7890을 사용합니다. 첫 번째 명령은 프록시를 명시적으로 우회하고, 두 번째 명령은 로컬 HTTP 프록시에 명시적으로 연결합니다. 실행하기 전에 TUN을 끄고 다른 VPN이 라우팅을 가로채지 않는지 확인하세요. 포트는 클라이언트의 실제 수신 포트로 바꾸세요. 조회 서비스에는 이번 요청과 요청 출처 주소가 전달됩니다.
# macOS / Linux: 직접 연결 요청
curl --noproxy "*" --max-time 15 https://api.ipify.org
# macOS / Linux: 로컬 프록시를 명시적으로 사용
curl --noproxy "" --proxy http://127.0.0.1:7890 --max-time 15 https://api.ipify.orgWindows PowerShell에서는 일부 환경에서 curl이 다른 명령으로 해석되는 것을 피하려면 curl.exe를 명시하는 것이 좋습니다. 프록시를 명시하는 테스트 전에 현재 터미널의 NO_PROXY 환경 변수를 잠시 지운 다음 실행하세요:
Remove-Item Env:NO_PROXY -ErrorAction SilentlyContinue
curl.exe --proxy http://127.0.0.1:7890 --max-time 15 https://api.ipify.org프록시를 명시한 명령이 성공하면 로컬 포트와 해당 요청 경로를 사용할 수 있다는 뜻입니다. 다만 이것만으로 시스템 프록시가 올바르게 설정됐다고 볼 수는 없습니다. 브라우저로 돌아가 로그를 확인해 브라우저 요청이 실제로 코어에 들어오는지도 확인하세요.
외부 IP 위치 데이터베이스는 업데이트가 늦을 수 있으며, 노드 이름과 실제 출구 도시는 일치한다고 보장할 수 없습니다. IPv4와 IPv6 결과도 다를 수 있습니다. 국기 아이콘만 보지 말고 조회 시간, 주소 유형, 매칭 정책, 출구 주소를 기록하세요. IP가 같더라도 규칙과 정책 경로를 함께 확인해 공유 출구나 주소 유형 차이를 연결 장애로 오인하지 않도록 하세요.
6. 브라우저는 되지만 다른 앱이 안 될 때 TUN 확인
시스템 프록시는 트래픽을 투명하게 가로채지 않습니다. 일부 게임, 명령줄 도구, 자체 네트워크 스택을 사용하는 앱은 시스템 프록시 설정을 읽지 않습니다. UDP 트래픽도 일반 HTTP 시스템 프록시만으로 연결할 수 있다고 기대해서는 안 됩니다. 먼저 앱 자체가 HTTP 또는 SOCKS 프록시를 지원하는지 확인한 다음 클라이언트의 TUN 모드를 사용할지 결정하세요.
TUN은 가상 네트워크 인터페이스와 라우팅 설정을 통해 조건에 맞는 트래픽을 코어로 전달합니다. 데스크톱에서는 관리자 권한, 서비스 모드 또는 네트워크 확장 권한이 필요할 수 있습니다. Android 클라이언트는 일반적으로 시스템 VPN 인터페이스를 사용합니다. 필요한 권한과 메뉴는 클라이언트 및 운영체제에 따라 다르므로 다른 플랫폼의 메뉴를 그대로 따라 해서는 안 됩니다.
- 시스템 프록시 경로가 정상 작동하는지 먼저 확인한 다음 TUN을 따로 테스트하세요. 노드 문제와 라우팅 문제를 한꺼번에 다루지 않도록 합니다.
- 다른 VPN, 가상 머신 네트워크, 기업 네트워크 정책과 충돌하는지 확인하세요.
- TUN을 켠 뒤 대상 앱의 연결 기록을 다시 확인하세요. ‘TUN 실행 중’이라는 사실만으로 프록시가 작동한다고 판단해서는 안 됩니다.
- LAN 기기에 연결할 수 없다면 방화벽부터 끄지 말고 라우팅 제외 설정과 직접 연결 규칙을 확인하세요.
IP 주소로는 접속되지만 도메인 이름이 해석되지 않는다면 DNS 설정과 코어의 해석 로그를 추가로 확인하세요. 시스템 프록시 사용 시의 DNS 처리, TUN의 DNS 가로채기, fake-ip 매핑은 서로 다른 기능입니다. 첫 점검부터 DNS 설정 전체를 함부로 복사하지 말고, 기존에 작동하는 설정은 유지한 채 어떤 도메인의 어떤 조회 요청이 실패했는지 확인하세요.
7. 자주 발생하는 문제와 점검 순서
| 증상 | 우선 확인할 항목 | 다음 조치 |
|---|---|---|
| 모든 노드에서 시간 초과 발생 | 구독 상태, 코어 실행 여부, 테스트 주소 | 설정을 업데이트하고 첫 오류를 확인한 뒤 다른 테스트 대상으로 바꿉니다. |
| 로컬 프록시 연결 거부 | 수신 포트와 코어 프로세스 | 실제 포트를 확인하고 포트 사용 충돌을 해결한 뒤 코어를 다시 시작합니다. |
| 속도 테스트는 성공하지만 웹페이지 접속 실패 | 대상 규칙, DNS, 노드에서 대상 사이트로 연결 가능한지 여부 | 대상 요청을 확인하고 다른 노드를 고정해 비교합니다. |
| IP 조회 결과가 여전히 직접 연결 주소 | 조회 도메인이 DIRECT에 매칭됐는지 확인 | 정책 경로를 확인하고 필요하면 잠시 전역 모드로 테스트 |
| 브라우저는 정상인데 앱은 실패 | 앱 자체 프록시 설정과 프로토콜 지원 여부 | 앱에 프록시를 설정하거나 TUN을 따로 테스트 |
| 클라이언트를 종료하면 인터넷 연결 불가 | 시스템에 남아 있는 로컬 프록시 설정 | 시스템 프록시를 끄고 직접 연결이 복구되는지 확인 |
한 번에 변수 하나만 바꾸세요. 노드, 모드, 포트, 연결 방식 중 하나씩 변경하고 변경 전후의 증상을 기록해야 효과가 있는 해결책을 찾기 쉽습니다. 인증서 오류가 발생하면 먼저 시스템 시간과 대상 웹사이트의 인증서 정보를 확인하세요. 첫 연결 테스트를 위해 TLS 검증을 건너뛰어서는 안 됩니다.
8. 첫 연결 완료 후 최종 점검
- 현재 구독이 활성화되어 있고 코어에서 오류가 계속 발생하지 않습니다.
- 기본 프록시 그룹과 최종 노드를 확인했습니다. 속도 테스트 수치만 기억해서는 안 됩니다.
- 시스템 프록시 주소와 실제 수신 포트가 일치합니다.
- 대상 요청이 연결 기록에 나타나고 예상한 정책에 매칭됩니다.
- 외부 IP와 로그 결과가 일치하며 직접 연결 규칙과 프록시 규칙을 구분했습니다.
- 평소 사용하는 규칙 모드로 되돌리고 임시 테스트 변경 사항을 취소했습니다.
- 클라이언트를 종료하기 전에 시스템 프록시를 끄거나 클라이언트가 시스템 설정을 올바르게 복원하는지 확인했습니다.
이 조건을 모두 충족해야 구독을 불러오는 단계부터 실제 접속까지의 점검이 완료됩니다. 이후 특정 웹사이트나 앱에서만 문제가 발생하면 클라이언트를 다시 설치하기보다 해당 서비스의 규칙, DNS, 연결 기록부터 확인하세요. 기본 사용법은 시스템 프록시 설정 안내를, 자세한 문제 해결 방법은 연결 점검 문서를 참고하세요.