확인 가능한 연결부터 시작하기
처음 사용할 때는 최소한의 항목만 확인하세요. 구성을 활성화하고, 규칙 모드로 전환한 뒤 노드를 직접 선택하고 시스템 프록시를 켜서 웹 요청을 한 번 보내면 됩니다. 프록시 클라이언트를 여러 개 동시에 실행하거나 처음부터 DNS, TUN, 규칙을 변경하지 마세요. 한 번에 한 가지 조건만 바꿔야 문제가 발생한 단계를 찾기 쉽습니다.
- 「구성」 또는 「Profiles」 페이지에서 구독을 가져온 다음 해당 구성을 선택하세요. 가져오기에 성공해도 자동으로 활성화된 것은 아닙니다. 프록시 페이지로 돌아가 프록시 그룹이 표시되는지 확인하세요.
- 실행 모드를 「규칙 / Rule」로 전환하세요. 처음 확인할 때는 구독에 포함된 규칙을 그대로 사용하고 사용자 지정 분기는 추가하지 마세요.
- 대상 프록시 그룹에서 노드를 하나 선택하고 지연 시간을 측정하세요. 선택한 항목이
DIRECT또는REJECT가 아닌지 확인합니다. - 데스크톱에서는 「시스템 프록시」를 켠 다음 브라우저에서 대상 웹사이트를 열고 「연결 / Connections」 페이지에서 해당 요청을 확인하세요.
프록시 그룹에서 실제 출구 노드 선택하기
「프록시 / Proxies」를 열고 노드를 바로 클릭하기 전에 규칙에서 실제로 사용하는 프록시 그룹부터 찾으세요. 구독에는 「노드 선택」, 「자동 선택」, 「해외 서비스」 등 여러 그룹이 포함될 수 있습니다. 그룹 이름은 구성 작성자가 정하는 것으로, 클라이언트에 고정된 메뉴 이름이 아닙니다. 한 그룹이 다른 그룹을 가리킬 수도 있으므로 선택 경로를 따라가 최종 노드를 확인해야 합니다.
자주 쓰이는 프록시 그룹 3가지와 선택 방법
| 그룹 유형 | 작동 방식 | 첫 연결 시 권장 작업 |
|---|---|---|
select | 직접 선택한 노드나 하위 그룹을 사용합니다. | 재검사하기 쉽도록 먼저 노드 하나를 지정하세요. |
url-test | 탐색 결과에 따라 출구를 자동으로 선택합니다. 전환 여부는 허용 오차 등 설정의 영향을 받습니다. | 그룹 이름만 보지 말고 현재 실제로 선택된 노드를 확인하세요. |
fallback | 일반적으로 구성에 지정된 순서에 따라 상태 확인을 통과한 출구를 선택합니다. | 지연 시간이 가장 짧은 순서로 정렬된다고 가정하지 마세요. |
예를 들어 대상 웹사이트가 「해외 서비스」 그룹에 연결되고, 이 그룹이 「노드 선택」을 사용하며, 「노드 선택」에서 「싱가포르 A」를 선택했다면 최종 출구는 「싱가포르 A」입니다. 관련 없는 다른 그룹만 변경해도 대상 웹사이트의 경로는 달라지지 않습니다. 노드 이름에 표시된 지역은 참고 정보일 뿐이므로 실제 출구 주소는 요청을 통해 확인해야 합니다.
DIRECT는 프록시 노드를 거치지 않고 직접 연결한다는 뜻입니다. 로컬 트래픽이나 직접 연결 규칙에는 사용할 수 있지만, 프록시 연결이 정상이라는 증거는 아닙니다.REJECT는 요청을 거부한다는 뜻입니다. 잘못 선택해 연결이 실패하더라도 예상된 동작입니다.- 노드가 많다면 제공 업체가 정상으로 표시한, 비교적 가까운 후보 두 개부터 선택하세요. 처음 문제를 확인할 때는 여러 노드를 연달아 바꾸지 않는 편이 좋습니다.
지연 시간 측정으로 알 수 있는 것
프록시 그룹 옆의 속도 측정 또는 지연 시간 버튼을 누르고 측정이 끝날 때까지 기다리세요. 일반적인 URL 지연 시간 측정은 노드를 통해 지정된 HTTP 또는 HTTPS 주소에 접속하고, 탐색이 완료될 때까지 걸린 시간을 기록합니다. 일반적인 ICMP Ping이나 다운로드 대역폭 측정과는 다릅니다. 테스트 URL, 연결 재사용, DNS, 노드 부하에 따라 결과가 달라질 수 있습니다.
세 차례 측정으로 안정성 확인하기
후보 노드를 하나 선택하고 동일한 테스트 주소로 약 5초 간격을 두고 세 차례 측정하세요. 결과를 기록한 뒤 다른 노드로 바꿔 비교합니다. 아래 결과는 판단 방법을 보여 주는 예시이며, 특정 노드에 대한 실제 측정값이나 속도 보장이 아닙니다.
| 후보 노드 | 3회 측정 예시 | 대응 방법 |
|---|---|---|
| 노드 A | 82 / 91 / 87 ms | 결과가 고르게 나와 웹페이지 확인용으로 먼저 사용하기 좋습니다. |
| 노드 B | 45 / 680 ms / 시간 초과 | 최저값은 낮지만 안정성은 확신하기 어렵습니다. |
| 노드 C | 세 차례 모두 시간 초과 | 노드와 테스트 대상을 교차해 확인하세요. |
자동 측정에는 https://www.gstatic.com/generate_204처럼 204를 반환하는 주소가 자주 사용됩니다. 이 주소에 접속할 수 있다고 해서 동영상 재생, 로그인, 파일 다운로드까지 정상이라는 뜻은 아닙니다. 반대로 특정 네트워크에서 측정 주소를 차단하면 사용 가능한 노드도 시간 초과로 표시될 수 있습니다. 실제 웹사이트 접속 결과도 함께 확인하고, 숫자 하나만으로 판단하지 마세요.
시스템 프록시를 켜고 요청이 코어에 전달되는지 확인하기
Windows 또는 macOS에서는 먼저 클라이언트의 「시스템 프록시」를 켜고 브라우저 트래픽을 확인하세요. 이 기능은 보통 시스템 프록시 주소를 로컬 수신 포트로 설정하지만 모든 애플리케이션의 연결을 강제로 프록시 처리하지는 않습니다. 브라우저 확장 프로그램, 앱 자체 프록시 설정, 일부 명령줄 프로그램은 시스템 프록시를 따르지 않을 수 있습니다.
포트를 확인한 뒤 프록시를 명시해 요청 보내기
「설정」 페이지에서 「포트」, 「혼합 포트」 또는 「Mixed Port」 항목을 찾으세요. 7890은 흔히 쓰이는 예시일 뿐, 모든 클라이언트의 고정값은 아닙니다. 아래는 구성 필드의 의미를 확인하기 위한 예시입니다. 현재 실행 중인 구성과 대조해서 사용하고 구독 파일을 그대로 덮어쓰지 마세요.
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
현재 혼합 포트가 실제로 7890인지 확인한 다음 Windows PowerShell에서 아래 명령을 실행하세요. macOS 또는 Linux에서는 curl.exe를 curl로 바꾸고, 포트가 다르면 명령의 숫자도 변경합니다.
curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 --head https://example.com/
- 이 명령은 로컬 HTTP 프록시를 명시적으로 지정하므로 앱이 시스템 프록시 설정을 읽는지 여부와 분리해 확인할 수 있습니다. 혼합 포트는 HTTP 프록시 요청을 지원합니다.
Failed to connect가 표시되고 주소가127.0.0.1을 가리킨다면 먼저 코어가 실행 중인지, 포트가 올바르게 입력되었는지 확인하세요.- 대상 서버에서 HTTP 응답을 받았다면 요청 경로에서 적어도 해당 통신은 완료된 것입니다. 응답이
403이어도 이를 곧바로 로컬 포트 문제로 분류해서는 안 됩니다. - 프록시를 명시한 요청은 성공하지만 브라우저에서 실패한다면 구독을 바로 바꾸기보다 시스템 프록시 설정, 브라우저 자체 프록시 설정, 확장 프로그램부터 확인하세요.
이 요청도 코어에 전달된 뒤에는 현재 규칙을 따릅니다. 직접 연결 규칙과 일치하면 DIRECT로 연결될 수도 있습니다. 따라서 명령 실행 성공은 프록시 진입점이 작동한다는 뜻일 뿐, 선택한 노드를 실제로 통과했는지는 연결 기록에서 확인해야 합니다. 수신 포트에 관한 설명은 전체 설치 가이드의 포트 설정을 참고하세요.
연결 기록에서 규칙과 노드 확인하기
「연결 / Connections」을 열고 도메인으로 필터링한 다음 대상 웹페이지를 새로고침하세요. 처음 확인할 때는 프록시를 통과해야 하는지 알고 있는 일반 웹페이지를 사용하세요. 기존 연결이 오래 유지되는 메신저 앱만 확인하지 마세요. 연결 기록이 빠르게 사라진다면 「로그 / Logs」도 함께 열고 info 수준에서 새 요청을 살펴보세요.
요청별로 확인할 네 가지 항목
- 대상 도메인 또는 주소: 백그라운드 업데이트나 다른 탭이 아니라 방금 연 웹사이트의 요청인지 확인하세요.
- 일치한 규칙: 도메인 규칙, 주소 규칙, 마지막 기본 규칙 중 무엇이 적용되었는지 확인하세요. 규칙은 보통 위에서 아래로 검사하며 먼저 일치한 항목이 이후 처리를 결정합니다.
- 프록시 경로: 그룹 이름을 따라가 최종 노드를 확인하세요. 결과가
DIRECT라면 해당 요청은 프록시 노드를 통과하지 않았습니다. - 전송량 변화: 새로고침한 뒤 업로드 및 다운로드 수치가 변하는지 확인하세요. 연결이 생성된 기록만 있고 응답 트래픽이 없다면 페이지가 정상적으로 열린다고 단정할 수 없습니다.
페이지에 표시된 출구 IP가 예상과 다르다면 같은 브라우저에서 신뢰할 수 있는 IP 조회 서비스에 접속하고, 해당 요청의 프록시 경로도 함께 확인하세요. IP 조회 사이트 자체에도 규칙이 적용되므로 직접 연결될 수 있습니다. 조회 결과는 그 요청의 출구만 보여 줄 뿐, 모든 앱이 같은 경로를 사용한다는 뜻은 아닙니다.
노드를 변경한 뒤에는 새 요청을 보내 확인하세요. 기존 TCP 연결이나 브라우저 연결 풀은 이전 경로를 계속 사용할 수 있습니다. 일부 클라이언트에는 「연결 닫기」 기능이 있지만, 실행하면 현재 전송이 중단되므로 파일을 다운로드하거나 회의 통화 중일 때는 사용하지 마세요. 규칙 적용 방식은 규칙 기반 트래픽 분기 안내에서 더 확인할 수 있습니다.
시스템 프록시와 TUN 중 선택하기
시스템 프록시로 브라우저 접속이 확인된 뒤 TUN 모드가 필요한지 검토하세요. TUN은 가상 네트워크 인터페이스를 통해 라우팅 조건에 맞는 트래픽을 처리하므로 시스템 프록시를 사용하지 않는 앱에 적합합니다. 다만 클라이언트에서 권한, 라우팅, DNS를 설정해야 합니다. 노드를 빠르게 만드는 기능이 아니며, 사용할 수 없는 구독을 복구해 주지도 않습니다.
- 데스크톱 브라우저 접속: 권한과 라우팅 변수를 줄이려면 먼저 시스템 프록시를 사용하세요.
- 게임 및 독립 네트워크 프로그램: 먼저 프록시 지원 여부를 확인하세요. 트래픽을 가로채야 하는 경우에만 TUN을 켜고 서비스 모드나 관리자 권한 안내를 확인합니다.
- Android 클라이언트: 보통 시스템 VPN 권한을 통해 트래픽을 처리하므로 데스크톱의 시스템 프록시 설정을 그대로 따라 하지 마세요. 다른 VPN 앱이 같은 연결 권한을 사용하려 할 수도 있습니다.
TUN을 활성화한 뒤에도 연결 기록을 다시 확인해야 합니다. UDP나 도메인 조회에만 문제가 생길 수 있으므로 웹페이지가 열린다고 모든 프로토콜이 정상이라고 판단하지 마세요. 처음 문제를 확인할 때는 다른 VPN을 동시에 실행하지 않는 것이 좋습니다. 업무 환경에서 회사 VPN이 필요하다면 조직의 네트워크 정책과 분기 방식을 먼저 확인하세요.
증상별로 첫 연결 실패 원인 찾기
| 증상 | 우선 확인할 항목 | 다음 단계 |
|---|---|---|
| 프록시 페이지에 노드가 표시되지 않음 | 구성이 활성화되었는지, 구독을 정상적으로 불러왔는지 확인합니다. | 구성 페이지로 돌아가 해당 항목을 선택하고 업데이트 또는 불러오기 오류를 확인하세요. |
| 모든 노드의 지연 시간 측정이 시간 초과됨 | 로컬 네트워크, 구독 상태, 측정 주소에 접속할 수 있는지 확인합니다. | 먼저 직접 연결 상태를 확인한 뒤 노드 두 개를 선택해 실제 웹페이지로 테스트하세요. |
| 지연 시간은 정상이지만 웹페이지가 열리지 않음 | 시스템 프록시 진입점, 규칙, 대상 서비스의 접속 제한을 확인합니다. | 프록시를 명시한 명령으로 테스트하고 연결 경로를 확인하세요. |
| 브라우저 요청이 연결 페이지에 표시되지 않음 | 브라우저가 프록시를 우회하는지, 다른 로컬 프록시를 사용하는지 확인합니다. | 브라우저 자체 설정을 확인하고 시스템 프록시 포트와 대조하세요. |
| 요청은 표시되지만 직접 연결로 나옴 | 일치한 규칙과 프록시 그룹에서 선택한 항목을 확인합니다. | 기본 노드 그룹만 바꾸지 말고 실제로 적용된 그룹을 확인하세요. |
| 특정 웹사이트 하나만 접속되지 않음 | 웹사이트 상태, 계정 지역, 노드 출구 제한을 확인합니다. | 다른 조건은 그대로 두고 노드 하나만 바꿔 비교하세요. |
오류가 발생하면 시간, 대상 도메인, 현재 모드, 노드 이름, 오류 메시지를 먼저 기록하세요. 로그를 공유하기 전에는 구독 URL, 토큰, 비밀번호, 개인 접속 기록을 삭제해야 합니다. 구독 주소에는 보통 접속 정보가 포함되므로 공개 게시판에 올리거나 온라인 변환 서비스에 함부로 입력하지 마세요.
첫 연결 완료 기준
구성이 활성화되고 후보 노드의 탐색이 완료되며, 실제 요청이 코어에 전달되고, 예상한 프록시 그룹 규칙이 적용되고, 최종 경로에 선택한 노드가 포함되며, 대상 페이지가 정상적으로 응답해야 합니다. 이 항목들이 시작 화면의 「연결됨」 표시보다 더 확실한 판단 기준입니다. 이후 필요에 따라 자동 선택, 구독 업데이트, 앱별 트래픽 분기를 설정하고, 설정을 바꿀 때도 같은 순서로 확인하세요.