VPN을 처음 접하면 조작 버튼보다 구독, 노드, 회선, 프로토콜, 트래픽 분할 같은 용어가 더 헷갈리기 쉽습니다. 이 용어들은 하나의 클라이언트에 함께 표시되지만 각각 설정의 출처, 접속 지점, 네트워크 경로, 전송 방식, 트래픽 처리 규칙을 뜻합니다. 각 요소의 역할을 먼저 나누어 이해하면 구독 가져오기, 노드 변경, 연결 끊김 문제 해결도 훨씬 수월해집니다.
먼저 한 가지 구분할 점이 있습니다. 일상적인 대화에서 VPN은 다양한 암호화 터널과 프록시 도구를 통칭하는 경우가 많지만, Shadowsocks, VMess, Trojan, VLESS, Hysteria2 및 TUIC은 더 정확히 말해 프록시 프로토콜 또는 전송 방식입니다. 클라이언트가 운영체제에서 제공하는 VPN 또는 TUN 인터페이스를 이용해 기기의 트래픽을 처리한다고 해서 이러한 프로토콜 자체가 전통적인 기업용 VPN인 것은 아닙니다. 이 차이를 이해하면 클라이언트 작동 모드와 노드 프로토콜을 같은 개념으로 혼동하지 않을 수 있습니다.
서비스·클라이언트·구독부터 구분하기
서비스와 클라이언트는 다릅니다
서비스는 노드 설정, 회선 리소스, 트래픽 규칙, 계정 관리 등 제공되는 내용을 뜻합니다. 클라이언트는 컴퓨터, 태블릿 또는 기타 기기에 설치하는 소프트웨어입니다. 클라이언트 자체에는 보통 사용할 수 있는 회선이 자동으로 포함되지 않습니다. 이메일 프로그램이 자동으로 이메일 주소를 제공하지 않는 것과 같습니다. 서비스에서 받은 설정을 호환되는 클라이언트로 가져와야 서버 주소, 포트, 프로토콜, 인증 정보를 인식할 수 있습니다.
하나의 서비스 설정이 여러 클라이언트와 호환될 수 있지만, 호환된다고 해서 기능까지 완전히 같은 것은 아닙니다. 어떤 클라이언트는 규칙 기반 분할과 TUN을 지원하고 다른 클라이언트는 시스템 프록시만 제공할 수 있습니다. 한쪽은 구독을 자동으로 업데이트하지만 다른 쪽은 수동 새로 고침이 필요할 수도 있습니다. 가이드의 화면이 다르게 보이면 버튼 색상만 보고 위치를 추측하지 말고 클라이언트 이름, 플랫폼, 버전을 먼저 확인하세요.
구독 링크는 업데이트되는 설정 진입점입니다
구독 링크는 일반적으로 계정에 전용으로 발급되는 웹 주소입니다. 클라이언트가 이 주소에 접속하면 노드 이름, 서버 접속 정보, 프로토콜 매개변수, 그룹 규칙 등을 가져옵니다. 일반 웹페이지나 브라우저로 열어야 하는 다운로드 페이지가 아닙니다. 브라우저에서 직접 열었을 때 인코딩된 텍스트, 다운로드 파일 또는 빈 페이지가 표시되어도 링크가 만료되었다는 뜻은 아닐 수 있습니다. 보통은 전체 링크를 클라이언트의 ‘구독’, ‘구성 파일’ 또는 ‘원격 설정’ 메뉴에 붙여 넣어야 합니다.
구독 링크에는 계정을 식별하는 토큰이 포함되는 경우가 많으므로 민감한 설정으로 관리해야 합니다. 공개 화면을 캡처할 때 전체 링크가 보이지 않게 하고, 출처가 불분명한 변환 사이트에 링크를 붙여 넣지 마세요. 유효한 구독을 다른 사람이 확보하면 노드 정보를 확인할 수 있으며, 서비스 제공자가 노드를 조정할 때 업데이트 내용까지 받을 수 있습니다.
‘구독 가져오기’와 ‘구독 업데이트’는 서로 다른 작업입니다. 가져오기는 클라이언트가 처음으로 설정 출처를 기억하게 하는 과정이고, 업데이트는 클라이언트가 원래 주소에 다시 접속해 서버의 최신 내용을 로컬에 동기화하는 과정입니다. 노드 이름, 접속 지점 또는 규칙이 바뀐 뒤 기존 노드만 전환해서는 문제가 해결되지 않을 수 있으므로 먼저 구독을 업데이트하세요. 일부 클라이언트는 업데이트할 때 구독 설정에 대한 로컬 변경 사항을 덮어쓸 수 있습니다. 장기간 유지할 사용자 지정 규칙은 클라이언트가 제공하는 덮어쓰기 또는 로컬 규칙 영역에 두는 편이 좋습니다.
- ✅ 복사한 주소가 처음부터 끝까지 완전한 구독 링크인지 확인하세요.
- ✅ 클라이언트의 구독 또는 원격 설정 메뉴에서 가져오고, 인코딩된 내용을 오류 페이지로 오해하지 마세요.
- ✅ 가져온 뒤 직접 업데이트를 실행하고 노드 목록이 표시되는지 확인하세요.
- ✅ 사용자 지정 규칙을 저장하기 전에 구독 업데이트가 로컬 변경 사항을 덮어쓰는지 확인하세요.
- ❌ 구독 링크를 공개하지 말고, 출처가 불분명한 온라인 변환 도구에 제출하지 마세요.
노드·서버·회선은 어떻게 다를까요?
노드는 클라이언트에서 선택할 수 있는 하나의 접속 설정입니다. 일반적으로 서버 주소, 접속 포트, 프로토콜, 인증 정보, 전송 매개변수가 포함됩니다. 목록의 ‘도쿄’, ‘로스앤젤레스’, ‘싱가포르’ 같은 이름은 알아보기 쉽게 붙인 표시명일 뿐이며, 서버 데이터센터·출구 주소·전체 네트워크 경로가 모두 같은 지역에 있다는 뜻은 아닙니다.
서버는 실제로 연결을 처리하는 소프트웨어와 컴퓨팅 리소스입니다. 하나의 서버가 여러 노드 설정을 수용할 수 있고, 하나의 노드가 먼저 중계 서버에 접속한 뒤 다른 출구를 통해 대상 웹사이트에 접근할 수도 있습니다. 따라서 ‘노드’는 클라이언트에 표시되는 설정 진입점에 가깝고, ‘서버’는 백엔드에서 실제로 작동하는 리소스에 가깝습니다.
회선은 로컬 환경에서 출구까지 데이터가 이동하는 대략적인 경로와 조정 방식을 뜻합니다. 회선 품질은 지리적 거리만으로 결정되지 않습니다. 통신사 간 연결, 우회 라우팅, 저녁 시간대 혼잡, 접속 지점의 부하, 대상 웹사이트의 네트워크 상태도 영향을 줍니다. 가까운 지역의 노드를 먼저 시도해 볼 만하지만, 국가나 지역 이름만 보고 결론을 내려서는 안 됩니다.
| 용어 | 실제로 의미하는 것 | 클라이언트에서 보이는 모습 | 문제 발생 시 먼저 확인할 사항 |
|---|---|---|---|
| 노드 | 선택 가능한 접속 설정 하나 | 노드 목록의 개별 항목 | 설정 만료 여부와 프로토콜 지원 여부 |
| 서버 | 접속·전송·출구 기능을 담당하는 소프트웨어와 리소스 | 백엔드 구조 전체가 표시되지는 않음 | 연결 수립 여부와 서버 응답 여부 |
| 회선 | 로컬·접속 지점·중계·출구 사이의 네트워크 경로 | 직접 연결·중계·전용 회선 등의 태그 | 혼잡·우회 경로·통신사 간 연결 상태 |
| 출구 주소 | 대상 웹사이트에 최종적으로 표시되는 공인 출발지 주소 | 연결 후 네트워크 검사로 확인 | 지역이 필요한 조건에 맞는지와 여전히 로컬 출구인지 확인 |
직접 연결·중계·IEPL 전용 회선
직접 연결은 일반적으로 기기가 서비스 제공자가 별도로 배치한 중계 노드 없이 해외 접속 지점에 직접 연결되는 방식을 뜻합니다. 구조가 단순하고 경로는 주로 로컬 통신사와 국제 인터넷 라우팅의 영향을 받습니다. 상호 연결이 원활할 때는 잘 작동하지만, 네트워크가 혼잡하거나 경로가 우회되면 변동이 더 크게 나타날 수 있습니다.
중계는 일반적으로 기기가 가까운 접속 지점이나 상호 연결 상태가 좋은 진입점에 먼저 연결한 뒤, 서비스 제공자가 관리하는 링크를 통해 출구로 전달하는 방식입니다. 중계의 가치는 통신망 경로를 다시 선택하는 데 있으며, 본질적으로 더 빠르다는 뜻은 아닙니다. 접속 지점, 전송 용량, 출구 부하 중 하나라도 적절하지 않으면 중계 효과가 상쇄될 수 있습니다.
IEPL은 원래 통신사가 제공하는 국제 이더넷 전용 회선 계열의 연결을 가리키며, 비교적 독립적이고 관리 가능한 국경 간 전송 경로라는 점에 초점을 둡니다. 실제 상품의 태그에서 ‘IEPL’은 회선 일부만 설명하는 경우도 있어, 사용자 측에서 공유 접속 지점이나 공용망 접속을 먼저 거칠 수 있습니다. 비교할 때는 서비스 제공자가 접속 지점·중계·출구를 어떻게 정의하는지 확인하고, 노드 이름만으로 전체 경로를 판단하지 마세요.
주요 프록시 프로토콜은 어떤 역할을 할까요?
프로토콜은 클라이언트와 서버가 데이터를 인증·암호화·캡슐화·전송하는 방식을 정합니다. 구독은 프로토콜 매개변수를 클라이언트에 전달할 뿐, 한 프로토콜을 다른 프로토콜로 자동 변환하지는 않습니다. 클라이언트가 노드에 사용된 프로토콜을 지원하지 않으면 노드를 가져올 수 없거나, 가져온 뒤 일부 필드가 누락되거나, 연결 버튼을 누르자마자 실패하는 현상이 나타날 수 있습니다.
| 프로토콜 | 핵심 특징 | 설정 시 확인할 사항 | 주로 적합한 상황 |
|---|---|---|---|
| Shadowsocks | 구조가 비교적 간단한 암호화 프록시 프로토콜 | 암호화 방식, 비밀번호, 서버와 포트가 일치해야 함 | 클라이언트 지원 범위가 넓어 일반적인 프록시 전송에 적합 |
| VMess | V2Ray 계열에서 초기에 사용된 인증 프로토콜 | 식별자, 전송 계층, 시간 동기화가 연결에 영향을 줌 | 기존 설정과 호환 환경에서 여전히 사용됨 |
| VLESS | 인증 및 전송 설계가 가볍고 다양한 전송 계층과 조합 가능 | 흐름 제어, 보안 계층, 도메인과 전송 매개변수가 일치해야 함 | 전송 방식을 유연하게 조합해야 하는 설정에 적합 |
| Trojan | 일반적으로 TLS를 기반으로 암호화 연결 수립 | 도메인, 인증서 검증, 비밀번호와 서버 이름이 정확해야 함 | TLS 설정이 완비된 서버와 클라이언트에 적합 |
| Hysteria2 | QUIC와 UDP를 기반으로 하며 지연이 높거나 패킷 손실이 있는 경로에서의 전송을 중시 | UDP 연결 가능 여부, 인증서, 대역폭 매개변수가 성능에 영향을 줌 | UDP 환경이 양호하고 클라이언트가 완전히 지원하는 네트워크에 적합 |
| TUIC | QUIC와 UDP를 활용해 다중 스트림 전송 | 인증, 혼잡 제어, 인증서와 클라이언트 버전이 일치해야 함 | 해당 프로토콜을 지원하고 UDP 통신을 허용하는 환경에 적합 |
프로토콜 이름만으로 최종 속도를 결정할 수는 없습니다. 회선이 혼잡한 상황에서는 캡슐화 방식을 바꿔도 용량 문제가 해결되지 않을 수 있습니다. 로컬 네트워크가 UDP를 제한하면 QUIC에 의존하는 방식은 연결되지 않을 수 있지만 TCP 또는 TLS 기반 설정은 작동할 수 있습니다. 반대로 지연과 패킷 손실이 뚜렷한 경로에서는 설계가 잘 된 QUIC 방식이 더 원활하게 복구될 수 있습니다. 네트워크 조건을 먼저 확인한 뒤 같은 시간대와 비슷한 출구 환경에서 여러 프로토콜을 비교하세요.
TLS라고 해서 ‘연결 성공’을 의미하는 것은 아닙니다. Trojan 또는 TLS를 사용하는 VLESS 설정에서는 클라이언트가 인증서와 서버 이름을 검증해야 합니다. 기기 시간이 크게 어긋났거나 도메인이 일치하지 않거나 인증서가 만료되었거나 클라이언트에서 필요한 검증을 끈 경우 핸드셰이크 오류가 발생할 수 있습니다. 인증서 오류가 발생하면 검증 해제를 장기적인 해결책으로 삼지 말고 설정을 수정하거나 구독을 업데이트하세요.
전체 모드·규칙 모드·직접 연결 모드 중 무엇을 선택할까요?
클라이언트의 ‘모드’는 트래픽의 이동 경로를 결정하는 기능이지 프로토콜을 바꾸는 버튼이 아닙니다. 전체 모드는 보통 클라이언트가 처리하는 트래픽을 모두 프록시 노드로 보냅니다. 규칙 모드는 도메인, 주소, 앱 또는 네트워크 유형을 먼저 확인한 뒤 프록시·직접 연결·차단 여부를 결정합니다. 직접 연결 모드는 프록시를 거치지 않고 트래픽을 보내 임시 점검이나 프록시 일시 중지에 사용합니다.
전체 모드는 검증에 적합하지만 장기 사용에 항상 알맞지는 않습니다
전체 모드는 규칙 흐름이 가장 단순하므로 설정을 가져온 직후 노드가 작동하는지 확인하기 좋습니다. 대상 웹사이트가 전체 모드에서는 정상이고 규칙 모드에서는 실패한다면 문제는 대개 노드가 아니라 규칙 매칭, DNS 결과 또는 클라이언트의 트래픽 처리 범위에 있습니다. 전체 모드를 장기간 유지하면 로컬 웹사이트, 로컬 네트워크 기기, 프록시가 필요 없는 다운로드 트래픽까지 원격 출구를 거치게 되어 경로가 길어지고 이용 경험이 저하될 수 있습니다.
규칙 모드는 ‘매칭 순서’에 좌우됩니다
규칙은 보통 앱, 도메인 접미사, 주소 범위처럼 더 구체적인 조건부터 확인하고, 마지막에 기본 규칙으로 일치하지 않은 요청을 처리합니다. 하나의 도메인이 여러 조건에 해당하면 클라이언트는 일반적으로 먼저 일치한 결과를 적용합니다. 범위가 넓은 규칙을 앞에 배치하면 뒤의 정확한 규칙이 작동하지 않을 수 있습니다.
규칙에서 ‘프록시’는 특정 노드를 직접 가리키지 않을 수도 있으며, 정책 그룹을 가리킬 수 있습니다. 정책 그룹은 수동 선택, 연결성 검사 또는 서버에서 전달한 로직에 따라 노드를 결정합니다. 따라서 규칙에 프록시라고 표시되어 있어도 트래픽이 원하는 지역의 출구를 사용한다고 단정할 수 없습니다. 정책 그룹의 현재 선택 항목과 실제 출구 주소를 확인해야 합니다.
시스템 프록시와 TUN은 처리 범위가 다릅니다
시스템 프록시는 운영체제 설정에 프록시 주소를 입력하는 방식이며, 이 설정을 따르는 앱이 클라이언트를 통해 트래픽을 전달합니다. 일부 게임, 명령줄 프로그램, 독립 네트워크 구성 요소, 자체 연결 방식을 사용하는 앱은 시스템 프록시를 무시할 수 있습니다. TUN 모드는 가상 네트워크 인터페이스를 만들어 더 낮은 계층에서 IP 트래픽을 처리하므로 적용 범위가 일반적으로 더 넓지만, 보안 소프트웨어·다른 VPN·가상 머신 네트워크·기업 네트워크 정책과 충돌하기도 쉽습니다.
- ✅ 노드를 처음 확인할 때는 전체 모드로 시작해 기본 연결과 출구가 정상인지 확인하세요.
- ✅ 전체 모드는 정상인데 규칙 모드에서 문제가 생기면 도메인 규칙, 정책 그룹, DNS 설정을 확인하세요.
- ✅ 브라우저는 정상인데 명령줄이나 독립 앱이 실패하면 해당 프로그램이 시스템 프록시를 따르는지 확인하세요.
- ✅ 더 많은 앱을 처리해야 할 때 TUN을 고려하되, 다른 네트워크 도구가 동시에 트래픽을 처리하고 있지 않은지 확인하세요.
- ❌ 트래픽을 처리할 수 있는 클라이언트를 여러 개 동시에 켜지 마세요. 라우팅과 DNS 설정이 서로 덮어쓸 수 있습니다.
DNS 누수·출구 주소·WebRTC는 무엇을 뜻할까요?
DNS는 도메인 이름을 네트워크 주소로 변환합니다. 프록시에 연결한 뒤에도 도메인 조회가 로컬 네트워크의 리졸버에서 직접 처리된다면, 사용자가 기대한 암호화 경로나 지정된 원격 리졸버를 거치지 않는 것이므로 일반적으로 DNS 누수라고 부릅니다. 이 현상이 즉시 웹페이지를 열 수 없게 만들지는 않지만 방문한 도메인이 노출되거나 프록시 출구와 맞지 않는 주소가 반환되어 규칙 판단 또는 지역별 접속에 문제가 생길 수 있습니다.
‘DNS를 프록시로 보낸다’와 ‘웹 트래픽을 프록시로 보낸다’는 별도의 설정입니다. 일부 클라이언트는 로컬에서 먼저 해석한 뒤 결과에 따라 트래픽을 분할하고, 일부는 도메인 규칙으로 경로를 결정한 다음 여러 리졸버에 조회를 맡깁니다. 또 다른 클라이언트는 가상 주소 매핑을 제공해 연결이 수립되기 전에도 도메인 규칙을 유지합니다. 클라이언트마다 구현이 다르므로 기계적으로 설정을 옮기지 말고, 특히 매핑 방식을 이해하지 못한 상태에서 DNS 설정 전체를 그대로 복사하지 마세요.
출구 주소는 웹사이트에 표시되는 공인 출발지 주소입니다. 연결 후에도 출구가 로컬 네트워크 주소로 표시된다면 현재 앱이 처리 대상에서 제외되었거나, 규칙이 직접 연결로 판단했거나, 클라이언트가 시스템 프록시만 설정했는데 앱이 이를 무시했을 가능성이 있습니다. 출구는 바뀌었지만 DNS 조회 위치가 예상과 다르다면 노드를 계속 바꾸기보다 DNS 경로를 별도로 점검하세요.
WebRTC는 브라우저와 실시간 통신 앱이 사용하는 기술 모음입니다. 일부 환경에서는 일반적인 페이지 요청과 다른 후보 네트워크 주소가 노출될 수 있습니다. 최신 브라우저, 운영체제, 네트워크 구조에 따라 처리 방식이 크게 다르므로 검사 페이지에 로컬 네트워크 주소가 하나 표시되었다는 이유만으로 프록시가 작동하지 않는다고 판단해서는 안 됩니다. 공인 후보 주소가 예상한 출구를 우회하는지, 브라우저가 현재 프록시 또는 TUN 라우팅을 따르는지를 확인하는 것이 중요합니다.
플랫폼별 클라이언트 조작 방식이 다른 이유
Windows와 macOS 클라이언트는 시스템 프록시와 TUN을 함께 제공하는 경우가 많지만, 가상 네트워크 구성 요소 설치, 시스템 권한 요청, 라우팅 충돌 처리 방식은 서로 다릅니다. 데스크톱 브라우저는 대체로 시스템 프록시를 읽지만 명령줄 도구는 환경 변수나 자체 프록시 옵션을 별도로 설정해야 할 수 있습니다. 터미널에서 연결에 실패했다고 해서 브라우저에서 사용하는 노드까지 작동하지 않는다고 단정할 수는 없습니다.
Android 클라이언트는 일반적으로 시스템 VPNService를 통해 트래픽을 처리하며, 앱별 프록시, 로컬 네트워크 우회, 앱별 프록시·직접 연결 선택 등을 지원하는 경우가 많습니다. 시스템 절전 정책이 클라이언트의 백그라운드 실행을 제한할 수 있으므로 화면을 잠근 뒤 자주 연결이 끊기면 프로토콜만 반복해서 바꾸지 말고 백그라운드 제한과 배터리 최적화를 확인하세요. 앱별 목록의 의미도 구분해야 합니다. 어떤 목록은 선택한 앱만 프록시를 사용한다는 뜻이고, 어떤 목록은 선택한 앱이 프록시를 우회한다는 뜻입니다.
iOS 클라이언트는 시스템이 제공하는 네트워크 확장 기능에 의존합니다. 구독을 가져온 뒤 처음 연결할 때는 보통 VPN 구성 추가를 허용해야 합니다. 규칙 세트, 스크립트, 프로토콜, 앱별 제어 지원 여부는 클라이언트마다 크게 다릅니다. 데스크톱 가이드의 TUN, 시스템 프록시, 복잡한 덮어쓰기 옵션을 iOS에서 그대로 찾을 수 없는 경우도 많습니다. 설정이 호환되지 않으면 알 수 없는 필드를 억지로 수정하지 말고 서비스가 명확히 지원하는 설정 형식을 사용하세요.
브라우저 확장 프로그램은 해당 브라우저에서 프록시 처리가 가능한 요청만 다루며 다른 앱, 시스템 업데이트, 명령줄 프로그램까지 자동으로 처리하지는 않습니다. 라우터 클라이언트는 해당 네트워크에 연결된 여러 기기를 처리할 수 있지만 규칙, DNS, 하드웨어 성능을 라우터가 모두 담당하므로 문제 해결은 더 어려워집니다. 초보자는 먼저 한 대의 기기에서 구독, 노드, 규칙을 확인한 뒤 라우터로 확장하는 편이 좋습니다.
| 플랫폼 또는 방식 | 일반적인 처리 방식 | 놓치기 쉬운 문제 |
|---|---|---|
| Windows | 시스템 프록시 또는 TUN | 명령줄 프로그램이 시스템 프록시를 읽지 않을 수 있으며, 가상 네트워크 구성 요소가 충돌할 수 있음 |
| macOS | 시스템 프록시 또는 네트워크 확장 | 시스템 권한, 프록시 우회 목록, 다른 네트워크 도구가 라우팅에 영향을 줌 |
| Android | 시스템 VPNService | 백그라운드 제한, 앱별 목록의 방향, 절전 정책 |
| iOS | 시스템 네트워크 확장 | 프로토콜 호환성, 설정 승인, 클라이언트 기능 차이 |
| 브라우저 확장 프로그램 | 브라우저 내부 요청만 처리 | 다른 앱은 브라우저와 함께 프록시를 사용하지 않음 |
| 라우터 | 네트워크 게이트웨이에서 통합적으로 트래픽 분할 | 규칙, DNS, 성능, 장애가 하위 기기에 영향을 줌 |
구독 가져오기부터 연결 검증까지의 전체 순서
초보자가 문제를 해결할 때 가장 흔히 하는 실수는 노드, 프로토콜, DNS, TUN, 규칙을 동시에 수정하는 것입니다. 그러면 어떤 변경이 효과가 있었는지 알 수 없습니다. 더 안정적인 방법은 정해진 순서에 따라 단계별로 확인하고, 각 단계에서 한 가지 요소만 검증하는 것입니다. 다음 절차는 원격 구독을 지원하는 대부분의 클라이언트에 적용할 수 있으며, 구체적인 버튼 이름은 사용하는 클라이언트에 따라 다를 수 있습니다.
- 클라이언트 호환성을 확인합니다. 먼저 플랫폼, 클라이언트 이름, 서비스가 지원하는 프로토콜을 확인하세요. 구독을 가져올 수 있다고 해서 현재 클라이언트가 모든 노드를 정확히 인식한다는 뜻은 아닙니다.
- 전체 구독 링크를 가져옵니다. 링크를 구독 또는 원격 설정 메뉴에 넣고, 알아보기 쉬운 이름을 지정한 다음 업데이트를 실행하세요.
- 업데이트 결과를 확인합니다. 클라이언트에 인증·형식·네트워크 오류가 없는지 확인하고 노드 목록이 표시되는지 점검하세요. 목록이 비어 있다면 속도 측정으로 넘어가지 말고 먼저 구독 문제를 해결하세요.
- 권장 노드를 선택합니다. 서비스에서 자주 사용하는 노드 또는 현재 위치의 네트워크와 상호 연결이 적합하다고 명확히 표시한 노드를 우선 선택하세요. 처음부터 이름만 보고 가장 빠른 회선을 추측하지 마세요.
- 전체 모드로 확인합니다. 연결을 수립한 뒤 네트워크 검사 페이지에 접속해 공인 출구가 바뀌었는지 확인하고, 대상 웹사이트 또는 앱을 테스트하세요.
- 규칙 모드로 전환합니다. 전체 모드가 정상이라면 규칙 모드를 활성화하고 자주 사용하는 웹사이트를 확인하세요. 로컬 서비스는 직접 연결하고 국제 서비스는 프록시를 사용하도록 설정할 수 있지만, 실제 경로는 규칙과 정책 그룹에 따라 달라집니다.
- 마지막으로 DNS 또는 TUN을 조정합니다. DNS 조회 위치가 이상하거나 일부 앱이 시스템 프록시를 따르지 않는 등 명확한 현상이 있을 때만 해당 옵션을 수정하세요.
느낌이 아니라 현상에 따라 원인을 찾으세요
- ✅ 구독이 업데이트되지 않음: 링크 완전성, 클라이언트 시간, 인증 상태, 현재 네트워크를 확인하세요.
- ✅ 노드 연결이 즉시 실패함: 프로토콜 지원, 인증 매개변수, TLS 검증, UDP 환경을 확인하세요.
- ✅ 브라우저는 정상인데 다른 앱이 실패함: 시스템 프록시 적용 범위, 앱 자체 프록시, TUN을 확인하세요.
- ✅ 전체 모드는 정상인데 규칙 모드가 실패함: 규칙 순서, 정책 그룹 선택, DNS 조회 결과를 확인하세요.
- ✅ 일정 시간 후 연결이 끊김: 로컬 네트워크 전환, 백그라운드 제한, 연결 유지 상태를 살펴보세요.
- ❌ 모든 설정을 동시에 바꾸지 마세요. 문제를 재현하고 실제 원인을 확인하기 어려워집니다.