VPN 초보자에게 용어가 많아 보여도 먼저 이해해야 할 관계는 몇 가지뿐입니다. 구독은 클라이언트에 설정을 전달하고, 노드는 클라이언트에서 선택하는 연결 진입점입니다. 회선 유형은 데이터가 출구에 도달하는 방식을 설명하고, 프로토콜은 클라이언트와 서버의 통신 방식을 정합니다. 트래픽 분할과 전체 모드·규칙 모드는 어떤 트래픽을 연결로 보낼지 결정합니다. 이 계층을 나누어 이해하면 설치, 회선 선택과 문제 해결이 훨씬 쉬워집니다.
가장 흔한 오해는 ‘노드’, ‘회선’, ‘프로토콜’과 ‘클라이언트’를 같은 개념으로 보는 것입니다. 예를 들어 하나의 노드는 VLESS 프로토콜을 사용할 수 있고, 서비스 제공업체가 중계 회선으로 표시할 수도 있습니다. 같은 구독을 여러 플랫폼의 호환 클라이언트에 가져올 수도 있습니다. 서로 관련되어 있지만 각각 해결하는 문제는 다릅니다.
구독, 구독 링크와 클라이언트는 무엇인가요
구독은 결제 기간이 아니라 동적으로 갱신되는 설정 목록입니다
프록시 클라이언트에서 ‘구독’은 일반적으로 서버에서 관리하는 설정 목록을 뜻합니다. 노드 이름, 서버 주소, 포트, 프로토콜 매개변수, 인증 정보와 전송 설정이 포함될 수 있습니다. 클라이언트는 구독 링크로 이러한 내용을 가져온 뒤 선택 가능한 노드 목록으로 변환합니다.
따라서 ‘구독 가져오기’는 네트워크 드라이버를 설치하는 것도, 연결이 완료되었다는 뜻도 아닙니다. 가져오기는 설정을 읽어오는 단계일 뿐입니다. 사용자는 노드를 선택하고 연결을 활성화한 다음, 시스템 트래픽이 클라이언트에서 처리되는지 확인해야 합니다. 구독은 가져와지지만 모든 노드에 연결할 수 없다면 구독 만료 여부, 클라이언트의 프로토콜 호환성, 시스템 시간의 정확성, 현재 네트워크에서 해당 전송 방식이 제한되는지 각각 확인하세요.
구독 링크에는 일반적으로 계정이나 요금제를 식별할 수 있는 인증 정보가 포함되므로 계정 비밀번호와 같은 수준으로 관리해야 합니다. 전체 링크를 공개 스크린샷, 포럼 게시물, 브라우저 동기화 메모나 공유 문서에 넣지 마세요. 다른 기기에서 사용해야 한다면 공개 채널로 전달하지 말고 신뢰할 수 있는 계정 패널에서 다시 복사하세요.
구독 업데이트와 다시 가져오기의 차이
‘구독 업데이트’는 클라이언트가 같은 구독 주소에 다시 요청을 보내 서버에서 현재 제공하는 노드와 매개변수를 가져오는 작업입니다. 회선 이름이 바뀌거나 오래된 노드가 제거되거나 프로토콜 매개변수가 조정된 경우, 로컬 설정을 직접 수정하기보다 업데이트하는 편이 적절합니다.
‘다시 가져오기’는 구독을 새로운 설정 출처로 클라이언트에 추가하는 작업입니다. 중복 이름의 구독을 처리하는 방식은 클라이언트마다 다릅니다. 기존 설정을 덮어쓰거나, 나란히 저장하거나, 사용자가 만든 규칙을 유지할 수 있습니다. 작업 전 로컬에서 직접 수정한 내용이 있는지 확인해 업데이트 과정에서 구독 내용으로 대체되지 않도록 하세요.
- ✅ 계정 패널에서 전체 구독 링크를 복사하고 링크의 문자를 직접 삭제하거나 수정하지 마세요.
- ✅ 클라이언트에서 ‘URL에서 가져오기’ 또는 이와 유사한 메뉴를 사용하세요.
- ✅ 가져온 뒤 먼저 구독을 업데이트하고 노드 목록이 표시되는지 확인하세요.
- ✅ 노드에 연결한 뒤 웹페이지 접속, DNS 조회와 자주 사용하는 앱을 각각 확인하세요.
- ❌ 구독 QR 코드, 전체 링크 또는 인증 필드가 포함된 설정 파일을 공개하지 마세요.
- ❌ ‘가져오기 성공’을 곧바로 ‘모든 트래픽이 연결을 통과한다’고 간주하지 마세요.
노드, 서버와 출구 IP의 관계
노드는 클라이언트가 사용자에게 보여주는 논리적 연결 항목입니다. 노드에는 최소한 연결 가능한 대상과 프로토콜 매개변수가 필요하지만, 노드 이름이 실제 물리 서버 이름과 같은 것은 아닙니다. 서비스 제공업체는 지역, 회선 유형이나 용도에 따라 노드 이름을 정할 수 있고, 여러 노드 진입점이 백엔드 자원을 공유하도록 구성할 수도 있습니다.
서버는 접속, 전달 또는 출구 기능을 담당하는 컴퓨팅 자원입니다. 하나의 연결이 접속 서버와 출구만 거칠 수도 있고, 추가 중계 단계를 포함할 수도 있습니다. 클라이언트는 내부 네트워크 구성을 보통 모두 표시하지 않으므로 노드 이름만으로 데이터가 실제로 몇 개의 네트워크 장비를 거쳤는지 판단할 수 없습니다.
출구 IP는 대상 웹사이트가 최종적으로 확인하는 출발지 주소입니다. 일반적으로 연결 경로 끝의 출구에 해당하며 사용자의 로컬 네트워크 주소와는 다릅니다. 진입 서버와 같은 네트워크에 있다는 보장도 없습니다. 지역이 예상과 맞는지 확인하려면 출구 IP의 지역 식별 결과를 확인하고 대상 서비스의 실제 동작도 함께 살펴보세요. 데이터베이스마다 같은 IP에 서로 다른 지역이나 통신사 태그를 표시할 수 있으므로 단일 조회 결과는 참고 자료로만 활용해야 합니다.
지연 시간, 대역폭과 안정성은 서로 다른 지표입니다
지연 시간은 데이터 왕복에 걸리는 시간으로, 물리적 거리, 우회 라우팅, 네트워크 혼잡과 무선 환경의 영향을 주로 받습니다. 대역폭은 단위 시간에 전송할 수 있는 데이터 양을 나타냅니다. 안정성은 지터, 패킷 손실, 연결 끊김과 장시간 사용 중의 변동에 더 초점을 둡니다.
지연 시간이 짧은 노드가 반드시 다운로드 속도가 빠른 것은 아니며, 대역폭이 큰 회선이 안정적인 상호작용이 필요한 회의나 원격 작업에 반드시 적합한 것도 아닙니다. 클라이언트 목록의 지연 시간 측정은 접속 지점이나 특정 테스트 주소만 확인하는 경우가 많아 대상 웹사이트의 실제 성능을 완전히 보여주지 못합니다. 회선을 선택할 때는 실제 작업을 기준으로 하세요. 웹페이지와 메신저는 응답성과 안정성이 중요하고, 대용량 파일 전송은 지속 처리량에 더 의존하며, 실시간 음성·영상은 지터와 패킷 손실의 영향도 받습니다.
IEPL 전용 회선, 중계와 직접 연결의 차이
회선 유형은 클라이언트 트래픽이 로컬 네트워크에서 원격 출구까지 이동하는 대략적인 경로를 설명합니다. 프로토콜 이름이나 암호화 알고리즘은 아닙니다. Shadowsocks, VMess 또는 Trojan은 서로 다른 회선에서 실행될 수 있으며, 반대로 같은 회선이 여러 프로토콜을 전달할 수도 있습니다.
| 회선 유형 | 기본 경로 | 일반적인 특징 | 확인할 점 |
|---|---|---|---|
| 직접 연결 | 로컬 네트워크가 원격 접속 지점에 직접 연결 | 구조가 비교적 단순하며 로컬 통신사에서 원격 지점까지의 공용망 라우팅에 큰 영향을 받음 | 저녁 시간대 혼잡, 망 간 우회와 지속 연결 성능 확인 |
| 중계 | 가까운 곳이나 라우팅이 양호한 진입점에 먼저 연결한 뒤 출구로 전달 | 일부 불리한 공용망 경로를 피할 수 있지만 중간 조정 단계가 추가됨 | 진입점 안정성, 출구 지역과 피크 시간대 변동 확인 |
| IEPL 전용 회선 | 접속 후 서비스 제공업체가 표시한 전용 회선 자원으로 양쪽 네트워크를 연결 | 일반적으로 경로 제어와 안정적인 전송을 강조하지만 구체적인 구현은 서비스 제공업체의 네트워크에 따라 달라짐 | 표시만 보지 말고 실제 연결과 대상 앱으로 확인 |
직접 연결의 장점은 경로 구조가 명확하고 중계 조정 단계가 하나 적다는 점입니다. 단점은 공용망의 국제 라우팅 변화에 더 쉽게 영향을 받을 수 있다는 것입니다. 사용자의 지역, 접속 통신사와 원격 서버 위치에 따라 결과가 달라지므로 같은 직접 연결 노드도 네트워크에 따라 성능 차이가 클 수 있습니다.
중계 회선은 먼저 트래픽을 하나의 접속 지점으로 보낸 뒤 서비스 제공업체의 전달 네트워크를 통해 출구로 전송합니다. 중계의 가치는 모든 상황에서 속도를 자동으로 높이는 것이 아니라 경로를 다시 구성하는 데 있습니다. 사용자와 진입점 사이가 안정적이어도 중계에서 출구로 가는 경로가 혼잡하면 실제 사용 경험은 저하됩니다.
IEPL은 국제 이더넷 전용 회선과 관련된 업계 용어입니다. 일반 사용자가 보는 노드 목록에서 ‘IEPL 전용 회선’은 보통 서비스 제공업체가 관련 기업 네트워크 자원을 사용했거나 회선 유형을 그렇게 표시했다는 뜻입니다. 하지만 이름만으로 전체 네트워크 구성, 용량과 조정 정책을 확인할 수는 없습니다. 구매나 문제 해결 시에는 이를 회선 설명으로 보아야 하며, 모든 대상 웹사이트에서 동일한 성능을 보장하는 표현으로 받아들여서는 안 됩니다.
주요 프로토콜의 차이
프로토콜은 클라이언트와 서버가 세션을 수립하고, 신원을 인증하고, 데이터를 캡슐화하며 트래픽을 전송하는 방식을 정합니다. 특정 프로토콜을 사용할 수 있는지는 서버가 해당 설정을 제공하는지, 클라이언트가 관련 기능을 구현했는지에 따라 달라집니다. 한 프로토콜의 링크를 완전히 호환되지 않는 클라이언트에 그대로 가져올 수는 없습니다.
Shadowsocks
Shadowsocks는 암호화 프록시 프로토콜로, 설정에는 보통 서버, 포트, 암호화 방식과 비밀번호가 포함됩니다. 구현이 성숙하고 지원하는 클라이언트가 많아 일반적인 네트워크 프록시 용도에 적합합니다. 구현에 따라 지원하는 암호화 스위트와 확장 기능이 다를 수 있으므로 가져오기에 실패하면 비밀번호나 포트를 임의로 바꾸기보다 클라이언트 버전과 설정 필드를 먼저 확인하세요.
VMess와 VLESS
VMess는 V2Ray 생태계에서 널리 사용되는 프록시 프로토콜로, 설정에 사용자 식별자, 전송 방식과 보안 매개변수가 포함됩니다. VLESS는 더 가벼운 프로토콜 설계를 사용하며 보통 TLS, REALITY 또는 다른 보안 전송 설정과 함께 구성합니다. 두 이름은 비슷하지만 설정 필드는 서로 바꿔 쓸 수 없습니다. 클라이언트에 ‘V2Ray 코어 호환’이라고 표시되어도 모든 전송 조합을 지원한다는 뜻은 아닙니다.
Trojan
Trojan은 보통 TLS 연결 위에서 실행되며, 설정에서 서버 도메인, 포트, 비밀번호, 인증서 검증과 전송 매개변수가 중요합니다. 인증서 이름 불일치, 잘못된 시스템 시간 또는 필요한 도메인 설정 누락으로 핸드셰이크가 실패할 수 있습니다. 인증서 검증을 끄면 오류가 일시적으로 사라지는 경우도 있지만 서버 신원 확인이 약해지므로 일반적인 해결 방법으로 사용해서는 안 됩니다.
Hysteria2와 TUIC
Hysteria2와 TUIC는 모두 QUIC 기반 전송 기능을 활용하며, 지연 시간이 높거나 지터·패킷 손실이 있는 환경에서 전송 효율을 높이는 데 초점을 두는 경우가 많습니다. 두 프로토콜은 UDP 통신에 의존합니다. 현재 네트워크가 UDP를 엄격히 제한하면 핸드셰이크 실패, 연결 후 트래픽 없음 또는 잦은 폴백이 발생할 수 있습니다. 이때는 먼저 UDP를 허용하는 네트워크에서 확인한 뒤 노드 장애인지 로컬 환경의 제한인지 판단하세요.
이 두 종류의 프로토콜이 모든 네트워크에서 반드시 더 빠른 것은 아닙니다. 네트워크가 안정적이고 대상과의 거리가 가깝다면 기존 TCP와 TLS 조합으로도 충분할 수 있습니다. 프로토콜은 이름의 신구보다 연결 성공률, 지속 전송과 앱 호환성을 기준으로 선택해야 합니다.
| 프로토콜 | 전송 특성 | 주요 점검 방향 |
|---|---|---|
| Shadowsocks | 암호화 프록시와 폭넓은 클라이언트 호환성 | 암호화 방식, 비밀번호, 포트, 클라이언트 구현 |
| VMess | 다양한 전송 조합과 생태계 호환성 | 사용자 식별자, 전송 계층, 경로와 보안 매개변수 |
| VLESS | 가벼운 프로토콜과 외부 보안 전송의 결합 | TLS 또는 REALITY 매개변수, 도메인, 전송 조합 |
| Trojan | TLS 기반 프록시 연결 | 인증서, 도메인, 시스템 시간과 비밀번호 |
| Hysteria2 | QUIC 기반, 변동이 있는 네트워크에 적합 | UDP 도달 가능성, 인증 정보와 대역폭 매개변수 |
| TUIC | QUIC 기반 프록시 전송 | UDP 제한, 인증서 검증과 혼잡 제어 호환성 |
전체 모드, 규칙 모드, 직접 연결과 시스템 프록시
노드에 연결한 뒤에도 클라이언트는 어떤 트래픽을 프록시 코어로 보낼지 결정해야 합니다. 이것이 실행 모드입니다. 클라이언트마다 명칭은 조금씩 다르지만 보통 전체 모드, 규칙 모드와 직접 연결 모드로 나눌 수 있습니다.
전체 모드
전체 모드는 클라이언트가 처리하는 트래픽을 가능한 한 현재 노드를 통과하도록 합니다. 노드 사용 가능 여부를 빠르게 확인하거나 여러 도메인을 사용하는 앱, 규칙을 작성하기 어려운 상황에 적합합니다. 단점은 로컬 서비스, 국내 웹사이트 또는 국제 연결이 필요 없는 앱도 원격으로 우회되어 지연 시간이 늘고 요금제 트래픽을 소모할 수 있다는 점입니다.
규칙 모드
규칙 모드는 도메인, IP, 앱 프로세스, 지역 데이터베이스 또는 사용자 지정 조건에 따라 프록시, 직접 연결이나 거부를 결정합니다. 장기 사용에는 더 적합하지만 정확성은 규칙의 품질에 달려 있습니다. 현대 앱은 로그인, 콘텐츠 전송, 업데이트와 원격 측정 등에 서로 다른 도메인을 자주 호출하므로 주 도메인만 추가하면 페이지는 열리지만 로그인, 이미지나 다운로드가 실패할 수 있습니다.
규칙은 보통 클라이언트에서 정한 순서대로 매칭됩니다. 범위가 넓은 규칙이 앞에 있으면 뒤의 정밀한 규칙이 적용되지 않을 수 있습니다. 문제를 확인할 때는 잠시 전체 모드로 전환해 보세요. 전체 모드에서는 작동하지만 규칙 모드에서 실패한다면 문제는 노드 자체보다 규칙, DNS 또는 앱 트래픽이 처리되지 않는 데 있을 가능성이 큽니다.
직접 연결 모드
직접 연결 모드는 트래픽이 원격 노드를 거치지 않도록 합니다. 클라이언트를 종료하지 않고 프록시를 일시 중지하거나 로컬 네트워크를 확인하거나 특정 웹사이트가 규칙의 영향을 받는지 테스트할 때 사용합니다. 일부 클라이언트의 ‘직접 연결’은 로컬 DNS, 트래픽 통계나 가상 네트워크 인터페이스를 유지할 수 있으므로 소프트웨어를 완전히 종료하는 것과 같지는 않습니다.
시스템 프록시와 TUN 모드
시스템 프록시는 운영체제나 앱에 HTTP, HTTPS, SOCKS 등의 프록시 주소를 제공합니다. 시스템 프록시 설정을 따르는 브라우저와 업무용 앱은 보통 처리할 수 있지만, 직접 연결을 생성하거나 시스템 프록시를 읽지 않는 프로그램은 이를 우회할 수 있습니다.
TUN 모드는 가상 네트워크 인터페이스를 통해 더 광범위한 IP 트래픽을 처리하며, 시스템 프록시를 지원하지 않는 앱, 게임 런처나 명령줄 도구에 자주 사용됩니다. 적용 범위가 넓은 만큼 라우팅 테이블, 방화벽, 다른 네트워크 소프트웨어와 권한 설정의 영향을 더 쉽게 받습니다. TUN을 활성화한 뒤 로컬 네트워크 기기에 접근할 수 없거나 네트워크 루프가 발생하거나 절전 모드 해제 후 연결이 끊기면 로컬 네트워크 우회 설정, 가상 네트워크 인터페이스 상태와 라우팅 충돌을 확인하세요.
앱 요청
├─ 직접 연결 규칙 일치 → 로컬 네트워크
├─ 프록시 규칙 일치 → 클라이언트 → 노드 → 대상 서비스
└─ 규칙 불일치 → 클라이언트의 최종 규칙에 따라 처리- ✅ 노드 테스트 단계에서는 먼저 전체 모드를 사용해 기본 연결이 성립하는지 확인하세요.
- ✅ 일상적인 사용에서는 규칙 모드로 전환해 로컬 서비스와 국제 연결을 분리해 처리하세요.
- ✅ 특정 앱이 작동하지 않으면 시스템 프록시를 따르는지 확인하고, 필요할 때 TUN을 검토하세요.
- ✅ 규칙을 수정한 뒤 클라이언트 연결 로그에서 요청이 실제로 어떤 규칙과 일치했는지 확인하세요.
- ❌ 우선순위를 이해하지 못한 상태에서 중복 규칙을 대량으로 추가하지 마세요.
- ❌ 시스템 프록시나 가상 네트워크 인터페이스를 변경하는 클라이언트를 여러 개 동시에 실행하지 마세요.
DNS 누출, 조회 경로와 트래픽 분할이 서로 영향을 주는 이유
DNS는 도메인 이름을 IP 주소로 변환합니다. 웹사이트에 접속하려면 클라이언트가 먼저 대상 주소를 알아야 하며, 이후 규칙에 따라 직접 연결할지 프록시를 사용할지 결정합니다. DNS 요청은 로컬 네트워크로 보내면서 실제 웹 트래픽은 원격 노드를 통과하면 조회 경로와 접속 경로가 일치하지 않을 수 있습니다.
DNS 누출은 일반적으로 프록시 측이나 지정된 리졸버가 처리해야 할 DNS 요청이 로컬 네트워크의 조회 서비스에 계속 노출되는 현상을 뜻합니다. 조회한 도메인이 드러날 수 있고, 출구 지역과 맞지 않는 주소가 반환되어 콘텐츠 전송 위치가 비정상적으로 선택되거나 접속 실패 또는 트래픽 분할 오판이 발생할 수도 있습니다.
규칙 모드는 특히 올바른 조회 결과에 의존합니다. 도메인 기반 규칙은 조회 전에 매칭할 수 있지만 IP나 지역 데이터베이스 기반 규칙은 조회 결과가 필요합니다. 브라우저에서 독립 보안 DNS를 사용하면 조회가 클라이언트 설정을 우회할 수 있고, TUN 모드가 DNS를 제대로 처리하지 못하면 웹 트래픽은 프록시를 통과하지만 DNS는 로컬로 나가는 상황이 발생할 수 있습니다.
DNS 문제를 점검할 때는 ‘웹페이지가 열리는지’만 보지 마세요. 클라이언트 로그에서 도메인, 리졸버, 일치한 규칙과 출구를 함께 확인해야 합니다. 노드를 바꿔도 변화가 없고 DNS 모드를 전환한 뒤 복구된다면 문제는 대개 회선 자체에 있지 않습니다. 반대로 DNS가 예상대로 처리되는데도 대상 연결이 계속 시간 초과되면 노드, 프로토콜과 네트워크 도달 가능성을 확인하세요.
플랫폼별 클라이언트 차이
같은 구독은 플랫폼이 달라도 표시되는 노드가 대체로 비슷하지만, 트래픽 처리 방식과 백그라운드 제한은 다를 수 있습니다. ‘컴퓨터에서는 되는데 다른 기기에서는 안 되는’ 상황이 발생해도 곧바로 구독이 만료되었다고 판단하지 말고 클라이언트 코어, 시스템 권한, 프록시 모드와 네트워크 환경을 먼저 비교하세요.
Windows
Windows 클라이언트는 보통 시스템 프록시와 TUN을 함께 제공합니다. 시스템 프록시는 브라우저와 시스템 설정을 따르는 프로그램에 적합하고, TUN은 더 많은 앱 트래픽을 처리해야 하는 상황에 적합합니다. 클라이언트를 종료한 뒤에도 웹페이지에 접속할 수 없다면 시스템 프록시가 올바르게 복원되었는지 확인하세요. TUN이 시작되지 않으면 가상 네트워크 인터페이스, 권한, 방화벽과 다른 네트워크 도구의 충돌을 확인해야 합니다.
Android
Android 클라이언트는 일반적으로 시스템 VPNService를 통해 트래픽을 처리하며, 처음 연결할 때 시스템 권한 승인 안내가 표시됩니다. 일부 시스템은 백그라운드 활동을 엄격히 제한해 화면을 잠근 뒤 연결을 종료할 수 있습니다. 기기의 배터리 관리 설정에서 클라이언트가 계속 실행되도록 허용하고, 시스템 VPN 인터페이스를 사용하는 다른 앱이 동시에 활성화되어 있지 않은지 확인하세요.
iOS와 iPadOS
이 플랫폼의 클라이언트는 시스템 네트워크 확장 기능에 의존해 연결을 수립합니다. 시스템 상태 표시줄에 연결 표시가 나타나도 확장 기능이 시작되었다는 뜻일 뿐, 대상 노드에 반드시 접속할 수 있다는 의미는 아닙니다. 실제 웹페이지, 클라이언트 로그와 출구를 확인해 판단해야 합니다. 구독에 포함된 일부 프로토콜이 표시되지 않는다면 같은 링크를 반복해서 가져오기보다 클라이언트의 지원 범위를 확인하세요.
macOS
macOS 클라이언트는 시스템 프록시, 네트워크 확장 기능 또는 가상 인터페이스를 사용할 수 있습니다. 브라우저는 정상인데 명령줄 도구가 작동하지 않는다면 후자가 시스템 프록시 환경을 읽지 않는 것이 흔한 원인입니다. TUN 사용 후 로컬 개발 서버나 로컬 네트워크 접근에 문제가 생기면 라우팅 제외 설정과 로컬 주소 규칙을 확인하세요.
가져오기부터 검증까지 전체 점검 절차
용어를 이해했다면 다음 순서로 설정을 깔끔하게 완료할 수 있습니다. 순서가 중요합니다. 먼저 설정 출처를 확인하고, 프로토콜 호환성을 점검한 다음 연결을 수립하고, 마지막으로 라우팅과 DNS를 확인하세요. 앞 단계를 건너뛰면 뒤에서 보이는 오류가 서로 섞이기 쉽습니다.
- 구독 가져오기. 서비스 패널에 로그인해 구독 또는 클라이언트 페이지에서 링크를 복사하세요. 불필요한 공백이 포함되지 않았는지 확인하고 공개 도구에서 구독을 펼치거나 변환하지 마세요.
- 호환 클라이언트 선택. 구독에 포함된 프로토콜을 확인하고 클라이언트가 해당 프로토콜과 전송 방식을 지원하는지 확인하세요. Shadowsocks만 지원하는 클라이언트는 완전한 VLESS, Trojan 또는 Hysteria2 설정을 직접 읽을 수 없습니다.
- 가져오기 및 업데이트. URL 가져오기 메뉴로 구독을 추가하고 업데이트를 실행한 뒤 노드 이름이 모두 표시되는지 확인하세요. 업데이트에서 인증 오류가 발생하면 계정 패널로 돌아가 링크를 다시 가져오고, 필드를 추측하거나 수정하지 마세요.
- 간단한 모드부터 검증. 현재 네트워크와 거리가 적절한 노드를 하나 선택하고 잠시 전체 모드를 사용하세요. 클라이언트에 연결 로그가 있다면 로그 창을 열어 DNS, 핸드셰이크와 시간 초과 오류를 구분할 수 있도록 하세요.
- 실제 출구 확인. 자주 사용하는 웹사이트를 열고 출구 지역이 노드 설명과 일치하는지 확인하세요. 클라이언트 내부의 지연 시간 버튼에만 의존하지 마세요. 테스트가 성공해도 대상 앱의 전체 요청이 성공한다는 뜻은 아닙니다.
- 규칙 모드로 전환. 기본 연결을 확인한 뒤 규칙 기반 트래픽 분할을 활성화하세요. 프록시가 필요한 서비스와 직접 연결이 필요한 서비스를 각각 테스트하고 요청이 어떤 규칙과 일치했는지 확인하세요.
- DNS 검증. 조회 요청을 예상한 구성 요소가 처리하는지 확인하세요. 브라우저와 다른 앱의 동작이 다르면 브라우저의 독립 DNS, 시스템 프록시와 TUN의 처리 범위를 점검하세요.
- 재현 가능한 설정 저장. 사용한 클라이언트 버전, 모드와 주요 스위치를 기록하되 구독 인증 정보는 기록하지 마세요. 문제가 생기면 한 번에 한 항목만 변경해 어떤 수정이 적용되었는지 판단할 수 있도록 하세요.
이 용어를 익히면 클라이언트 화면이 서로 무관한 스위치의 모음처럼 보이지 않습니다. 구독은 설정 배포를 담당하고, 노드는 연결 진입점을 제공하며, 회선은 전송 경로를 정하고, 프로토콜은 통신을 담당하고, 실행 모드는 트래픽을 선택하며, DNS는 도메인 조회와 규칙 판단에 영향을 줍니다. 문제가 발생하면 이 흐름을 따라 단계별로 확인하는 편이 클라이언트를 자주 바꾸거나 설정을 반복해서 가져오는 것보다 효과적입니다.