Clash PC 버전 첫 연결: 노드 선택·지연 시간 테스트·프록시 작동 확인
Clash 클라이언트를 처음 설치했다면 순서대로 노드 선택, 지연 시간 확인, 시스템 프록시 설정을 진행하고 브라우저와 연결 로그에서 프록시 적용 여부를 확인하세요.
1. 연결 전 확인: 설정, 코어, 수신 포트
첫 연결은 ‘설정 불러오기 → 출구 선택 → 노드 테스트 → 브라우저 연결 → 연결 기록 확인’ 순서로 진행하세요. 구독을 성공적으로 가져왔다는 것은 클라이언트가 설정을 받은 것일 뿐입니다. 노드 사용 가능 여부, 규칙 적용 여부, 앱 연결 여부는 각각 따로 확인해야 합니다. 시스템 프록시, TUN 모드, 브라우저 프록시 확장 프로그램을 한꺼번에 켜지 마세요. 문제가 생겼을 때 어느 단계에서 실패했는지 찾기 어려워집니다.
- 현재 설정을 확인하세요. 클라이언트의 ‘구독’ 또는 ‘설정’ 페이지에서 방금 가져온 설정을 선택하고, 목록에 표시되기만 하는 것이 아니라 실제로 사용 중인지 확인합니다. 페이지 이름은 클라이언트 버전에 따라 다를 수 있습니다.
- 코어가 실행 중인지 확인하세요. ‘로그’ 페이지에서 설정 파싱 오류, 포트 충돌, 코어 종료 메시지가 있는지 확인합니다. 화면이 열려 있다고 해서 코어가 정상적으로 시작된 것은 아닙니다.
- 로컬 포트를 확인하세요. 설정에서 ‘포트’, ‘혼합 포트’ 또는
mixed-port를 찾습니다. 이 문서에서는127.0.0.1:7890을 예시로 사용합니다. 화면에 다른 포트가 표시된다면 이후 명령에서도 해당 포트로 바꿔야 합니다. - 중복 연결 경로를 잠시 끄세요. 다른 프록시 클라이언트와 브라우저 프록시 확장 프로그램을 종료하고, 명확한 연결 경로 하나만 남겨 둡니다. 연결 테스트를 위해 방화벽이나 인증서 검사를 끄지 마세요.
설정 페이지에 노드가 없다면 먼저 설정 가져오기 단계로 돌아가세요. 구독이 유효한지, 요금제가 만료되지 않았는지, 가져온 항목이 Clash YAML 설정인지 다른 형식의 노드 목록인지 확인합니다. 이때 지연 시간 테스트를 반복해도 누락된 설정이 생기지는 않습니다.
2. 프록시 그룹 선택: 모드를 정한 다음 실제 노드 선택
프록시 그룹은 노드 자체가 아닙니다. 여러 노드를 포함할 수도 있고, 다른 프록시 그룹을 참조할 수도 있습니다. 규칙 모드에서는 접속 대상에 따라 서로 다른 그룹이 적용될 수 있으므로 노드 하나를 선택했다고 해서 모든 트래픽이 그 노드를 통과하는 것은 아닙니다.
첫 연결은 규칙 모드로 진행
클라이언트의 ‘프록시’ 페이지에서 실행 모드를 ‘규칙’(Rule)으로 설정합니다. 설정에서 일반 프록시 트래픽에 사용하는 그룹을 찾아 펼친 다음 실제 노드를 선택하세요. 그룹 이름은 설정 작성자가 정하므로 이름만 보고 용도를 판단하지 말고, 규칙 대상과 연결 기록을 함께 확인해야 합니다.
| 모드 또는 옵션 | 기능 | 첫 연결 시 참고 사항 |
|---|---|---|
| 규칙 모드 Rule | 설정된 규칙에 따라 직접 연결 또는 프록시 사용 | 일상적인 연결 확인을 시작할 때 권장 |
| 전역 모드 Global | 전역 정책에서 출구 선택 | 규칙 문제를 분리해 확인할 때 잠시 사용할 수 있지만, 유효한 출구를 선택해야 합니다 |
| 직접 연결 모드 Direct | 직접 연결 출구 사용 | 선택한 프록시 노드로 일반 요청을 전달하지 않음 |
| DIRECT | 프록시 정책의 직접 연결 동작 | 프록시 노드가 아닙니다 |
| 자동 선택 그룹 | 보통 url-test 등의 방식으로 출구를 결정 | 그룹에서 현재 실제로 선택된 노드 확인 |
예를 들어 규칙에서 특정 사이트를 ‘미디어’ 그룹으로 보내는데 ‘기본 프록시’ 그룹만 바꿨다면 해당 사이트의 출구는 그대로일 수 있습니다. 그룹 이름은 설명을 위한 예시이므로 실제 작업에서는 현재 설정에 표시된 이름을 기준으로 하세요. 그룹 안에 ‘자동 선택’ 단계가 더 있다면 계속 펼쳐 최종 노드를 확인합니다.
수동으로 선택한 뒤 새 요청은 보통 새 출구를 사용하지만, 기존 장기 연결은 이전 출구를 계속 사용할 수 있습니다. 테스트할 때는 페이지를 새로 열거나 브라우저 창을 새로 만드세요. 연결을 끊어야 한다면 다운로드나 회의를 중단하지 않도록 전체 연결을 지우기보다 해당 테스트 연결만 종료하는 것이 좋습니다.
3. 지연 시간 테스트: 연결 가능 여부를 확인하고, 밀리초를 다운로드 속도로 오해하지 않기
‘프록시’ 페이지에서 노드나 그룹 옆의 테스트 버튼을 누르고 한 차례 테스트가 끝날 때까지 기다린 뒤 결과를 비교합니다. 일반적인 테스트는 코어가 노드를 통해 지정된 HTTP 또는 HTTPS 주소에 요청을 보내고 소요 시간을 기록하는 방식입니다. 단순한 ICMP ping도, 전체 대역폭 테스트도 아닙니다.
테스트 결과 읽는 법
- 밀리초 값이 표시됨: 해당 노드가 이번 테스트 조건에서 요청을 완료할 수 있다는 뜻입니다. 결과는 테스트 주소, 핸드셰이크, 네트워크 혼잡, 캐시의 영향을 받습니다.
- 시간 초과 또는 실패: 제한 시간 안에 유효한 결과를 얻지 못했다는 뜻입니다. 노드 연결 불가, 테스트 대상 제한, DNS 오류, 테스트 조건 불일치 등이 원인일 수 있습니다.
- 수치가 낮아도 웹페이지가 느림: 테스트 대상과 실제 웹사이트가 서로 다른 경로를 사용할 수 있습니다. 대역폭 부족, 패킷 손실, 사이트 응답 지연도 지연 시간 수치 하나로는 모두 파악할 수 없습니다.
예를 들어 같은 노드의 연속 세 차례 결과가 82 ms, 91 ms, 87 ms이고, 다른 노드는 45 ms, 시간 초과, 310 ms라면 첫 번째 노드로 첫 연결 확인을 계속 진행하는 편이 좋습니다. 이는 결과 읽는 법을 보여 주는 예시이며, 이 사이트에서 직접 측정한 값이 아니고 노드 다운로드 속도를 추정할 근거도 아닙니다.
동일한 테스트 조건에서 비교
클라이언트에서 테스트 주소를 설정할 수 있다면 먼저 설정에 등록된 주소를 사용하고, 현재 네트워크에서 접속 가능한지 확인하세요. 연결 확인용으로 흔히 쓰는 주소는 https://www.gstatic.com/generate_204이며, 예상 응답은 HTTP 204입니다. 다만 네트워크에 따라 이 주소에 접속할 수 없을 수도 있습니다. 주소를 바꾼 뒤에는 이전 결과와 새 결과를 직접 비교하지 않는 것이 좋습니다.
처음 문제를 확인할 때는 테스트 간격을 약 10초로 두고 3회 진행하세요. 여러 노드에 테스트를 연달아 반복하는 것은 피합니다. 노드 하나만 실패하면 다른 노드로 확인하고, 모든 노드가 실패한다면 설정 유효 기간, 코어 로그, 로컬 네트워크를 먼저 점검하세요. 테스트 시간 제한을 줄이면 실패를 더 일찍 알 수 있을 뿐 노드가 빨라지지는 않습니다.
4. 시스템 프록시 켜기: 브라우저 요청을 클라이언트로 전달
노드 테스트는 보통 코어가 직접 요청하므로 시스템 프록시가 꺼져 있어도 성공할 수 있습니다. 시스템 프록시 설정을 따르는 브라우저가 클라이언트를 거치게 하려면 클라이언트에서 ‘시스템 프록시’를 켜야 합니다. 첫 연결을 확인하는 동안에는 설정 변수를 줄이기 위해 TUN 모드를 꺼 두세요.
- 클라이언트에서 ‘시스템 프록시’를 켠 다음 스위치가 바로 꺼지거나 설정 적용 실패 메시지가 나타나지 않는지 확인합니다.
- Windows 11에서 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’를 열고 ‘수동 프록시 설정’ 영역을 확인합니다. 필요한 경우 ‘편집’을 눌러 주소와 포트를 확인하세요.
- 로컬 프록시 주소는 보통
127.0.0.1이며, 포트는 클라이언트에서 제공하는 HTTP 포트 또는 혼합 포트와 일치해야 합니다. 구독 URL을 프록시 서버 주소에 입력하지 마세요. - 별도의 프록시 규칙이 설정되지 않은 브라우저 창으로 테스트 사이트에 접속하고, 동시에 클라이언트의 ‘연결’ 페이지에서 새 요청이 표시되는지 확인합니다.
PAC 방식으로 연결 중이라면 시스템 설정에 수동 서버 대신 자동 구성 스크립트가 표시될 수 있습니다. 문제를 확인할 때 다른 프록시 설정을 수동으로 추가해 겹쳐 쓰지 마세요. 첫 연결에서는 한 가지 방식만 선택하고, 성공 여부를 확인한 뒤 변경하세요.
TUN 모드는 시스템 프록시를 따르지 않는 앱을 처리할 때 유용합니다. 추가 권한이 필요할 수 있고 가상 네트워크 어댑터, 라우팅, DNS 설정도 관련됩니다. 특정 앱의 트래픽이 TUN으로 전달되는지는 실제 설정에 따라 달라집니다. 시스템 프록시만으로 브라우저 연결을 확인할 수 있다면 ‘연결됨’ 상태를 보기 위해 TUN을 바로 켤 필요는 없습니다.
5. 브라우저와 연결 로그: 규칙 및 출구 확인
프록시가 제대로 작동하려면 두 가지를 모두 확인해야 합니다. 대상 앱의 요청이 실제로 클라이언트에 들어오고, 최종적으로 예상한 출구를 사용해야 합니다. 브라우저에서 페이지가 열린다는 사실만으로는 직접 연결인지 프록시 연결인지 알 수 없고, 지연 시간 테스트 성공만으로 브라우저가 연결됐다고 볼 수도 없습니다.
연결 페이지에서 동일한 요청 찾기
- 클라이언트의 ‘연결’ 페이지를 열고 도메인 필터를 사용하거나 새로 추가된 기록을 확인합니다.
- 브라우저에서 명확한 HTTPS 사이트에 접속하고 접속 시각과 도메인을 기록합니다. 테스트 페이지는 공개적으로 접속할 수 있으므로 계정에 로그인할 필요가 없습니다.
- 해당 연결의 대상 도메인, 일치한 규칙, 정책 경로, 업로드·다운로드 변화를 확인합니다. 표시되는 항목 이름은 클라이언트마다 다를 수 있습니다.
- 정책 경로의 최종 항목이
DIRECT라면 요청이 클라이언트에 들어왔지만 직접 연결로 전달된 것입니다. 최종 항목이 선택한 노드여야 해당 연결이 그 프록시 출구를 사용한 것입니다.
짧은 연결은 금방 끝나 화면을 전환하기 전에 사라질 수 있습니다. 먼저 연결 페이지를 열고 브라우저를 새로 고치거나 ‘로그’ 페이지에서 같은 시각의 규칙 적용 기록을 찾아보세요. 로그 수준이 info이면 보통 연결 정보를 확인할 수 있지만, 구체적인 내용은 코어와 클라이언트에 따라 다릅니다. 특정 문구가 없다는 이유만으로 오류라고 판단하지 마세요.
추가 확인이 필요하다면 신뢰할 수 있는 공인 IP 조회 페이지를 이용할 수 있습니다. 프록시 사용 전후의 출구 주소와 네트워크 정보를 비교하되 국가나 지역 표시만으로 노드 위치를 판단하지 마세요. IP 데이터베이스 업데이트가 늦을 수 있고, 사이트가 규칙에 따라 직접 연결될 수도 있습니다. 연결 기록과 IP 조회 결과를 함께 확인하세요.
6. 명령줄로 재확인: 로컬 수신과 원격 연결 실패 구분
브라우저 동작이 불분명하다면 Windows PowerShell이나 터미널에서 HTTP 프록시를 명시해 요청을 보낼 수 있습니다. 이 방법은 브라우저의 프록시 선택 과정을 건너뛰므로 시스템 프록시 스위치가 적용됐음을 증명하지는 않습니다. 먼저 예시 포트가 현재 설정과 일치하는지 확인하세요.
curl.exe -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7890 https://example.com/-I는 응답 헤더를 요청합니다. --connect-timeout 10은 연결 단계의 대기 시간을 10초로 제한하고, --max-time 20은 전체 요청 시간을 20초로 제한합니다. 터미널에 NO_PROXY 환경 변수가 설정되어 있다면 테스트 도메인이 예외로 등록되어 있는지 확인하고, 클라이언트에 해당 연결이 표시되는지도 살펴보세요.
- 로컬 포트에 연결할 수 없음: 코어가 실행 중인지, 포트를 잘못 입력하지 않았는지, 해당 포트가 HTTP 프록시를 제공하는지 먼저 확인하세요.
- HTTP 200 Connection established가 표시됨: 프록시 터널이 만들어졌다는 뜻일 뿐입니다. 이후 TLS 연결과 대상 서버의 응답도 확인해야 하며, 이 한 줄만으로 요청 전체가 성공했다고 판단할 수 없습니다.
- 대상 서버의 응답 헤더를 받음: 명시적으로 프록시를 지정한 요청에서 해당 HTTP 통신이 완료됐다는 뜻입니다. 대상 서버가
403을 반환했다면 웹사이트의 접근 거부와 연결 자체의 실패를 구분하세요. - 인증서 오류가 발생함: 시스템 시간, 인증서 신뢰 상태, 네트워크 환경을 확인하세요. 인증서 검사를 건너뛰는 방식으로 계속 사용하는 것은 피해야 합니다.
포트가 수신 대기 중인지 확인하려면 Windows 터미널에서 다음 명령을 실행하세요.
netstat -ano | findstr ":7890"로컬 주소 열에서 포트가 7890이고 상태가 LISTENING인 항목을 찾습니다. 이 필터에는 관련된 다른 행도 표시될 수 있으므로 각 열을 확인하세요. PID에 해당하는 프로세스는 작업 관리자의 ‘세부 정보’에서 찾을 수 있습니다. 수신 대기 항목이 있다는 것은 프로그램이 포트를 사용 중이라는 뜻일 뿐이므로, 현재 클라이언트의 코어가 사용하는 포트인지도 확인해야 합니다.
7. 흔한 결과 비교 및 첫 연결 마무리
| 증상 | 먼저 확인할 항목 | 다음 단계 |
|---|---|---|
| 지연 시간 테스트는 성공했지만 브라우저 연결 기록이 없음 | 시스템 프록시, 브라우저 개별 프록시, 우회 목록 | 시스템 포트를 확인하고 중복 프록시 연결 경로를 끄세요 |
| 브라우저 기록은 있지만 출구가 DIRECT | 실행 모드와 적용된 규칙 | 해당 사이트가 원래 직접 연결되어야 하는지 확인하세요 |
| 프록시를 명시한 명령은 성공하지만 브라우저는 실패 | 브라우저 설정, 확장 프로그램, 시스템 프록시 상태 | 새 브라우저 창에서 다시 테스트하고 같은 도메인의 연결 기록을 확인하세요 |
| 노드 하나만 시간 초과되고 다른 노드는 정상 | 해당 노드 상태와 테스트 대상의 호환성 | 사용 가능한 노드로 바꾸고 구독 제공자에게 문의하세요 |
| 모든 노드와 프록시 명시 요청이 실패 | 설정, 코어 로그, 로컬 네트워크, 구독 상태 | 구체적인 오류부터 해결하고 모드를 반복해서 바꾸지 마세요 |
| 브라우저는 정상이지만 특정 앱은 연결되지 않음 | 해당 앱이 시스템 프록시를 따르는지 여부 | 앱의 프록시 옵션을 확인한 뒤 TUN이 필요한지 검토하세요 |
첫 연결을 마친 뒤에는 재현하기 쉬운 상태를 유지하세요. 규칙 모드, 사용 가능한 것으로 확인된 노드, 실제 수신 포트, 연결 페이지에서 찾을 수 있는 테스트 요청을 기록해 둡니다. 전역 모드로 잠시 바꿨다면 규칙 모드로 되돌리고, 로그 수준을 올렸다면 평소 사용하는 수준으로 복원하세요.
클라이언트를 종료하기 전에 시스템 프록시를 끄세요. 클라이언트가 중지된 뒤에도 시스템이 더 이상 수신하지 않는 로컬 포트를 가리키는 일을 방지할 수 있습니다. 종료 후 브라우저가 인터넷에 연결되지 않으면 Windows 프록시 설정에서 남아 있는 항목을 확인하세요. 이후 시작 프로그램 설정이나 TUN 연결을 조정할 때는 한 번에 하나씩만 바꾸고 브라우저와 연결 로그를 다시 확인하세요.
연결 성공 여부는 녹색 상태 표시나 특정 밀리초 값 하나로 판단할 수 없습니다. ‘앱 요청이 클라이언트에 들어옴, 예상한 규칙이 적용됨, 최종 노드가 명확함, 대상 서버가 정상 응답함’의 전체 흐름을 확인해야 합니다. 기본 사용법은 사용 가이드를 참고하세요. 구체적인 오류가 있다면 도움말 센터에서 증상에 따라 계속 확인할 수 있습니다.