프록시 첫 연결 가이드: Clash Verge Rev 노드 선택·핑 테스트·IP 확인

1. 연결 전 확인: 설정 활성화 및 코어 실행 여부

구독을 가져오면 노드와 규칙이 클라이언트에 추가되지만, 브라우저가 곧바로 프록시를 사용한다는 뜻은 아닙니다. 연결을 완료하려면 설정 활성화, 정책 선택, 앱 트래픽의 코어 전달, 요청이 예상한 노드에서 나가는지 확인까지 네 단계를 거쳐야 합니다. 하나라도 빠지면 노드 지연 시간은 표시되지만 웹페이지가 열리지 않을 수 있습니다.

이 글에서는 Clash Verge Rev 데스크톱 버전에서 흔히 볼 수 있는 화면을 기준으로 설명합니다. 버전에 따라 버튼 이름이나 설정 메뉴 구성이 다를 수 있으므로, 설치된 버전의 실제 화면을 기준으로 확인하세요. Clash Verge Rev는 설정과 인터페이스를 관리하고, mihomo는 프록시 연결, DNS 처리, 규칙 매칭을 담당하는 코어입니다.

사이드바에서 「프로필」로 이동해 가져온 구독이 있는지, 현재 설정으로 선택되어 있는지 확인하세요. 목록에 카드가 보인다고 해서 활성화된 것은 아닙니다.
「프록시」로 이동해 정책 그룹과 그룹에 속한 노드가 표시되는지 확인하세요. 빈 화면만 보여서는 안 됩니다. 그룹 이름은 구독 제공자가 정하며, 「노드 선택」, 「프록시」 등으로 표시될 수 있습니다.
「로그」를 열고 가장 최근 설정을 정상적으로 불러왔는지 확인하세요. YAML 파싱 오류, 포트 수신 대기 실패, 코어의 반복 종료가 보이면 먼저 해당 문제를 해결해야 합니다.
현재 프록시의 수신 주소와 포트를 확인해 두세요. 아래 명령은 127.0.0.1:7897을 예시로 사용합니다. 실제 포트는 클라이언트 설정의 혼합 포트를 확인해야 하며, 예시를 그대로 복사하면 안 됩니다.

2. 노드 이름만 누르지 말고 정책 그룹에서 노드 선택하기

「프록시」를 열고 현재 작업 모드를 확인하세요. 처음에는 Rule(규칙) 모드를 사용하는 것이 좋습니다. 요청은 설정된 규칙에 따라 DIRECT, 프록시 정책 그룹 또는 REJECT로 전달됩니다. Global(전역) 모드는 코어에 들어온 요청을 전역 정책에 전달하지만 모든 앱의 트래픽을 자동으로 가로채지는 않습니다. Direct(직접 연결) 모드는 프록시 출구를 확인하는 데 적합하지 않습니다.

규칙에서 실제로 참조하는 정책 그룹 찾기

정책 그룹은 규칙과 노드 사이에서 선택을 담당합니다. 예를 들어 규칙이 특정 도메인의 트래픽을 「노드 선택」 그룹으로 보내더라도, 현재 선택된 항목이 DIRECT라면 다른 그룹에서 해외 노드를 선택해 둔 경우에도 요청은 직접 연결될 수 있습니다. 대상 사이트의 트래픽을 처리하는 그룹을 펼친 다음 그 안에서 구체적인 노드를 선택하세요.

select: 수동 선택 방식입니다. 첫 검증에 적합하며, 노드를 하나 선택하면 테스트 조건을 일정하게 유지할 수 있습니다.
url-test: 상태 점검 결과에 따라 노드를 자동으로 선택합니다. 테스트 결과에 따라 현재 노드가 바뀔 수 있으므로, 이전에 표시된 선택이 계속 유지된다고 보면 안 됩니다.
fallback: 일반적으로 설정 순서에 따라 사용 가능한 노드를 선택하며, 지연 시간이 가장 짧은 노드를 우선 선택하는 것은 아닙니다.

그룹 안에 다른 정책 그룹이 포함되어 있다면 실제 사용할 노드가 확인될 때까지 계속 펼쳐 보세요. 노드 이름에 표시된 국가, 배율, 용도는 제공자가 입력한 설명일 뿐 실제 출구 위치를 검증한 결과가 아닙니다. 처음에는 위치가 적절하고 상태가 정상인 일반 노드를 선택한 뒤 지연 시간을 비교하세요.

3. 지연 시간 테스트: 연결 여부를 먼저 확인하고 안정성을 살펴보세요

정책 그룹이나 노드 옆의 지연 시간 테스트 버튼을 누르세요. 보통 클라이언트는 테스트 대상 노드를 통해 테스트 URL에 접속한 뒤 요청에 걸린 시간을 표시합니다. 측정 범위는 코어와 테스트 방식에 따라 다릅니다. 단순한 ICMP ping도, 다운로드 속도 측정도 아니며 모든 웹사이트에 접속할 수 있음을 보장하지도 않습니다.

조건을 통제하고 세 차례 연속 테스트하기

결과에 영향을 줄 수 있으므로 먼저 대용량 파일 다운로드와 속도 측정을 중지하세요.
같은 그룹을 세 번 테스트하세요. 매회 5~10초 정도 간격을 두고 후보 노드가 반복해서 시간 초과되는지 확인합니다.
여러 차례 테스트를 완료한 노드를 먼저 고른 다음 지연 시간을 비교하세요. 한 번 측정한 최저값만 보고 결정하지 마세요.

예를 들어 노드 A는 세 번의 테스트에서 86, 92, 89ms가 나오고, 노드 B는 45ms, 시간 초과, 410ms가 나온다면 첫 연결에는 A가 더 적합합니다. 숫자는 결과를 해석하는 방법을 보여 주기 위한 예시이며 실제 측정값이 아닙니다. 짧은 시간 동안의 사용 가능성을 판단할 때는 한 번의 낮은 지연 시간보다 안정성이 더 중요합니다.

timeout이 발생하면 먼저 테스트 실패 범위를 구분하세요

timeout은 제한 시간 안에 이번 테스트가 완료되지 않았다는 뜻이지, 구독이 만료되었다는 의미는 아닙니다. 테스트 주소의 DNS 조회 실패, 노드 경로 연결 불가, 테스트 사이트의 접속 거부도 비슷한 결과를 낼 수 있습니다. 모든 노드에서 동시에 시간 초과가 발생하면 노드를 수십 개씩 바꾸기보다 먼저 로컬 네트워크, 구독 유효 기간, 로그를 확인하세요.

설정에서 https://www.gstatic.com/generate_204를 테스트 주소로 사용한다면 예상 응답은 HTTP 204입니다. 요청은 성공했지만 응답 본문이 없다는 뜻입니다. 이 주소에 접속할 수 있는지는 확인 항목 중 하나일 뿐입니다. 지연 시간이 정상이어도 다음 단계에서 대상 웹사이트에 접속해 확인해야 합니다.

4. 시스템 프록시를 켜 브라우저 요청을 코어로 전달하기

노드를 선택한 다음 「설정」으로 이동해 「시스템 프록시」를 켜세요. 설정 페이지가 항목별로 나뉘어 있다면 시스템 프록시는 보통 네트워크 관련 영역에 있습니다. 「LAN 연결 허용」을 시스템 프록시 스위치와 혼동하지 마세요. 이 옵션은 다른 기기가 로컬 프록시 포트에 접속하도록 하는 기능이며, 현재 기기에서 인터넷에 접속하는 데 필요한 설정은 아닙니다.

시스템 프록시는 운영체제의 프록시 설정이 로컬 수신 포트를 가리키도록 합니다. Windows에서는 시스템 「설정」→「네트워크 및 인터넷」→「프록시」에서 확인할 수 있습니다. macOS에서는 「시스템 설정」→「네트워크」→현재 네트워크 연결→「세부사항」→「프록시」로 이동하세요. 주소와 포트가 클라이언트의 실제 수신 값과 일치하는지 확인해야 합니다.

Chrome, Edge 등의 브라우저는 보통 시스템 프록시를 사용하지만, 브라우저 확장 프로그램이나 실행 옵션, 기업 정책에 따라 설정이 달라질 수 있습니다.
Firefox에서는 프록시를 별도로 설정할 수 있습니다. 시스템 설정을 따르지 않는다면 「설정」→「일반」→「네트워크 설정」에서 시스템 프록시 설정 사용을 선택하세요.
명령줄 도구와 일부 게임은 시스템 프록시를 사용하지 않을 수 있습니다. 브라우저에서 접속된다고 해서 모든 프로그램의 트래픽이 프록시로 전달되는 것은 아닙니다.

5. 연결 화면에서 요청의 규칙과 노드 확인하기

클라이언트의 「연결」 화면을 열어 둔 상태에서 브라우저로 새 웹 요청을 보내세요. 이미 로드된 정적 페이지만 확인하지 마세요. 기존 탭을 닫고 다시 접속하거나 새 시크릿 창을 사용하면 캐시와 기존 연결의 영향을 줄일 수 있습니다. 시크릿 창을 사용해도 프록시 설정 자체는 달라지지 않습니다.

연결 목록에서 도메인으로 대상 요청을 필터링하고 연결 상세 정보를 펼치세요. 화면에 따라 관련 항목이 「규칙」, 「매칭 규칙」, 「경로」, 「프록시 체인」 등으로 표시될 수 있습니다. 다음 세 가지 정보를 확인하세요.

확인 항목	확인할 내용	결과 의미
대상 주소	도메인이나 대상 IP가 방금 보낸 요청과 일치하는지 확인	백그라운드 업데이트 요청을 이번 테스트로 잘못 판단하지 않도록 합니다
적용된 규칙	예: DOMAIN-SUFFIX, GEOSITE 또는 MATCH	현재 설정에서 이 정책이 선택된 이유를 확인합니다
프록시 경로	정책 그룹과 최종 노드 또는 DIRECT, REJECT	요청이 실제로 프록시, 직접 연결, 거부 중 어떤 방식으로 처리됐는지 판단합니다

한국 내 사이트에 DIRECT 규칙이 적용되어도 반드시 오류인 것은 아닙니다. 규칙에 따라 일부 트래픽을 직접 연결하는 것은 정상입니다. 다만 프록시를 통해 접속해야 하는 사이트에 DIRECT가 표시된다면 시스템 프록시를 다시 켜기만 할 것이 아니라 적용된 규칙과 정책 그룹 선택을 확인하세요.

연결 화면에 새 기록이 전혀 없다면 브라우저가 실제로 로컬 프록시를 사용 중인지, 목록에 필터가 설정되어 있는지 먼저 확인하세요. 짧은 요청은 금방 사라질 수 있으므로 연결 화면을 먼저 열고 대상 페이지를 새로고침한 뒤 로그도 함께 살펴보세요. 잠시 목록이 비어 있다는 이유만으로 노드를 사용할 수 없다고 판단하지 마세요.

6. 외부 IP 비교: 프록시 사용 여부를 결과로 확인하기

연결 경로에서 노드가 확인되면 IP 조회 서비스에 접속해 공인 IP 주소를 기록하세요. 먼저 시스템 프록시를 끄고 TUN도 꺼져 있는지 확인한 뒤 IP를 다시 조회해 직접 연결 기준값을 확보합니다. 이후 시스템 프록시를 다시 켜고 새 페이지에서 IP를 조회하세요. 지역 표기가 데이터베이스마다 다를 수 있으므로 가급적 같은 조회 서비스를 사용해 비교하세요.

IP 조회 페이지에도 규칙이 적용됩니다. 해당 요청에 DIRECT가 적용되면 로컬 출구 IP가 표시되는 것이 정상이며, 이 결과만으로 다른 사이트가 프록시를 사용하지 않았다고 판단할 수 없습니다. IP 조회 요청의 연결 기록도 함께 확인하세요. IP에 표시된 지역은 참고 정보일 뿐이며, 주소가 바뀌었는지와 경로가 예상한 노드를 통과하는지가 더 중요합니다.

명시적 프록시 명령으로 브라우저 설정 문제 분리하기

브라우저 결과가 불분명하다면 아래 두 명령으로 IPv4 출구를 비교해 보세요. Windows PowerShell에서는 실행 파일을 지정하는 curl.exe를 사용하는 것이 좋습니다. macOS와 Linux에서는 curl을 사용하세요. 예시의 포트 7897은 클라이언트의 실제 혼합 포트로 바꿔야 합니다.

# Windows: curl 프록시 설정을 사용하지 않고 직접 연결 기준 IP 조회
curl.exe -4 --noproxy "*" --max-time 15 https://api.ipify.org

# Windows: 로컬 HTTP 프록시에 명시적으로 연결
curl.exe -4 --proxy http://127.0.0.1:7897 --noproxy "" --max-time 15 https://api.ipify.org

# macOS / Linux
curl -4 --noproxy "*" --max-time 15 https://api.ipify.org
curl -4 --proxy http://127.0.0.1:7897 --noproxy "" --max-time 15 https://api.ipify.org

--max-time 15는 요청 1회의 전체 제한 시간을 15초로 설정합니다. -4는 두 요청 모두 IPv4를 사용하게 해 IPv4와 IPv6 주소 차이를 프록시 효과로 오인하지 않도록 합니다. 프록시 명령에 빈 --noproxy를 지정하면 환경에 설정된 우회 목록이 해제됩니다. 단, 명시적 프록시도 코어의 라우팅 모드와 규칙을 따르므로 모든 대상이 선택한 노드를 통과하도록 강제하지는 않습니다.

직접 연결 기준값을 얻으려면 TUN과 다른 VPN도 꺼져 있어야 합니다. --noproxy는 curl의 프록시 설정만 우회할 뿐 시스템 수준의 트래픽 전달은 우회하지 못합니다. 명령에서 127.0.0.1에 연결할 수 없다고 나오면 먼저 수신 포트와 코어 실행 상태를 확인하세요. 명시적 프록시 명령은 성공하지만 브라우저에서 실패한다면 브라우저 설정이나 확장 프로그램을 중점적으로 살펴보세요.

7. 첫 연결 확인 및 이후 TUN 테스트

신뢰할 수 있는 검증에는 서로 일치하는 세 가지 근거가 필요합니다. 노드 테스트가 완료되고, 대상 요청의 연결 경로가 예상한 노드를 가리키며, 외부 IP 조회 결과가 해당 경로와 일치해야 합니다. 웹페이지가 열리거나 지연 시간 표시가 녹색이라는 사실만으로는 충분히 확인했다고 볼 수 없습니다.

지연 시간은 정상인데 웹페이지가 열리지 않음: 시스템 프록시와 실제 수신 포트를 확인하고, 연결 화면에서 대상 도메인에 적용된 규칙을 살펴보세요.
웹페이지는 열리지만 외부 IP가 바뀌지 않음: 먼저 IP 조회 요청에 DIRECT가 적용됐는지 확인한 다음 브라우저가 프록시를 우회하는지 살펴보세요.
외부 IP는 바뀌었지만 특정 사이트에 접속할 수 없음: 해당 사이트의 연결 기록과 로그를 확인하고 노드 출구 제한, DNS 결과, 사이트 자체의 접속 정책을 점검하세요.
브라우저는 되지만 다른 앱은 실패함: 해당 앱이 시스템 프록시를 지원하는지 확인하세요. 필요한 경우 TUN을 통한 트래픽 전달을 검토하세요.

TUN 모드는 가상 네트워크 인터페이스를 통해 더 많은 IP 트래픽을 전달하므로 시스템 프록시를 사용하지 않는 앱에 적합합니다. 하지만 시스템 프록시와는 별개의 기능입니다. 사용하려면 서비스 모드나 관리자 권한이 필요할 수 있으며, 다른 VPN의 라우팅과 충돌할 수도 있습니다. 이미 정상 작동하는 설정과 노드는 유지하고 트래픽을 전달하는 방식만 바꾼 뒤 대상 앱의 연결 경로를 다시 확인하세요.

마지막으로 현재 설정 이름, 정책 그룹에서 선택한 항목, 혼합 포트를 기록해 두면 다음에 비교하기 편합니다. 지원을 요청할 때는 클라이언트 버전, 운영체제 버전, 민감 정보를 가린 오류 로그와 연결 결과를 제공하세요. 구독 URL, 노드 비밀번호, 액세스 토큰은 공개하지 마세요. 이 확인을 모두 마쳐야 요청이 코어에 들어와 예상한 프록시 노드에서 나간다고 볼 수 있습니다.