VPN 용어를 처음 접할 때 가장 헷갈리는 부분은 특정 단어가 어려워서가 아니라, 구독·노드·회선·프로토콜·클라이언트가 한 화면에 함께 표시되는 경우가 많기 때문입니다. 실제로 이들은 서로 다른 계층에 속합니다. 구독은 설정을 전달하고, 노드는 출구 정보를 제공하며, 회선은 데이터가 거치는 경로를 나타냅니다. 프로토콜은 클라이언트와 서버의 통신 방식을 정하고, 분할 라우팅 규칙은 어떤 요청을 이 경로로 보낼지 결정합니다.

이 개념들을 나누어 보면 하나의 연결은 다음과 같이 이해할 수 있습니다. 클라이언트가 구독에 포함된 노드 설정을 읽고, 현재 모드에 따라 분할 라우팅 규칙을 적용한 뒤, 지정된 프로토콜로 조건에 맞는 트래픽을 노드로 보냅니다. 노드는 원격에서 대상 웹사이트에 접속하므로 상대방에게는 사용자의 현재 네트워크 공인 출구가 아니라 노드의 출구 주소가 표시됩니다. 어느 한 계층의 설정이라도 맞지 않으면 연결 실패, 웹사이트의 지역 판정 오류, 일부 앱 미적용 또는 도메인 해석 이상으로 나타날 수 있습니다.

구독, 구독 링크, 클라이언트는 각각 무엇일까

구독은 업데이트 가능한 설정 목록입니다

구독은 하나의 회선도, 설치 파일도 아닙니다. 일반적으로 서비스 측에서 관리하는 설정 목록으로, 노드 이름·서버 주소·포트·프로토콜 유형·인증 정보·전송 매개변수 등이 포함될 수 있습니다. 클라이언트가 이 목록을 읽어야 화면에 선택 가능한 노드가 생성됩니다.

구독 내용이 변경되면 클라이언트에서 업데이트 또는 새로고침을 실행해야 새로운 노드 설정을 받을 수 있습니다. 앱 화면만 전환하는 것은 구독 업데이트와 다르며, 반대로 구독을 업데이트해도 현재 노드가 자동으로 바뀌지는 않습니다. 자동 업데이트 방식은 클라이언트마다 달라서 시작할 때 새로고침하는 경우도 있고, 수동 조작이 필요하거나 업데이트 정책을 직접 설정할 수 있는 경우도 있습니다.

구독 링크는 설정을 가져오는 입구이므로 공개 공유를 피해야 합니다

구독 링크는 설정 목록을 읽는 입구로 볼 수 있으며, 구독 권한을 식별하는 토큰이 포함될 수 있습니다. 이 링크를 얻은 사람은 해당 설정을 읽을 수 있으므로 전체 링크를 공개 페이지, 스크린샷 또는 공개 코드 저장소에 올려서는 안 됩니다. 문제를 확인하기 위해 링크 구조를 보여줘야 한다면 도메인 뒤의 인증 매개변수와 쿼리 내용을 가려야 합니다.

구독 링크를 복사한 뒤에는 일반적으로 클라이언트에서 “URL에서 가져오기”, “구독 추가” 또는 “원격 설정”과 같은 메뉴를 찾아 사용해야 합니다. 브라우저 주소창에 붙여넣어 다운로드한 뒤 직접 실행하는 방식은 적절하지 않습니다. 일부 서비스는 특정 클라이언트 형식만 지원합니다. 가져온 뒤 노드가 나타나지 않는다면 링크가 완전히 복사되지 않았거나, 클라이언트가 반환 형식을 지원하지 않거나, 구독이 아직 업데이트되지 않았거나, 로컬 네트워크에서 설정을 받아오지 못한 것이 흔한 원인입니다.

클라이언트는 설정을 읽고 트래픽을 처리합니다

클라이언트는 기기에서 실행되는 프로그램입니다. 구독 관리, 노드 선택, 프로토콜 구현, 라우팅 처리, DNS 처리, 연결 상태 표시 등을 담당합니다. 같은 구독을 여러 클라이언트에 가져오면 노드 자체는 같을 수 있지만, 사용할 수 있는 규칙 모드·시스템 프록시·TUN 처리·로그 도구에는 차이가 생길 수 있습니다.

용어 주요 역할 흔한 오해
구독 업데이트 가능한 노드 설정을 저장하고 배포 구독 자체가 현재 사용 중인 노드라고 생각함
구독 링크 클라이언트가 원격 설정을 가져오도록 함 일반 다운로드 주소이므로 공개 전달해도 된다고 생각함
클라이언트 설정을 해석하고 프로토콜을 구현하며 기기 트래픽을 처리 모든 클라이언트의 모드 이름과 기능이 완전히 같다고 생각함
설정 파일 노드·규칙·DNS·라우팅 매개변수를 저장 가져오기에 성공하면 모든 앱이 이미 처리된다고 생각함
  • ✅ 서비스 패널에서 전체 구독 링크를 복사하고 불필요한 공백이나 줄바꿈이 없는지 확인합니다.
  • ✅ 항목별로 서버 매개변수를 추측하지 말고 클라이언트의 구독 또는 원격 설정 메뉴에서 가져옵니다.
  • ✅ 가져온 뒤 구독을 직접 업데이트하고 노드 목록이 표시되는지 확인합니다.
  • ✅ 노드를 선택해 연결을 시작한 다음 대상 앱에서 실제 출구를 확인합니다.
  • ❌ 공개 스크린샷, 채팅방 파일 또는 코드 저장소에 전체 구독 링크를 표시하지 않습니다.
이 절의 결론: 구독은 “설정이 어디에서 오는가”를 해결하고, 클라이언트는 “설정을 어떻게 실행하는가”를 담당합니다. 가져오기에 성공했다는 것은 클라이언트가 설정을 읽었다는 뜻일 뿐이며, 실제로 트래픽이 처리되는지는 노드 상태와 실행 모드, 시스템 권한을 함께 확인해야 합니다.

노드, 서버, 회선은 왜 같은 개념이 아닐까

노드는 일반적으로 클라이언트에서 선택할 수 있는 하나의 설정 항목입니다. 특정 진입 서버에 연결하는 데 필요한 정보가 포함되며, 지역·용도·회선 유형 태그가 함께 표시되기도 합니다. 서버는 네트워크 서비스를 제공하는 실제 장비 또는 인스턴스입니다. 여러 노드 설정이 동일한 인프라를 가리킬 수도 있고, 포트·프로토콜·진입점·출구가 달라 별도로 표시될 수도 있습니다.

회선은 현재 네트워크에서 원격 출구까지 데이터가 거치는 경로를 뜻합니다. 사용자가 선택하는 것은 노드지만 실제 사용감은 로컬 통신망, 진입 위치, 망간 경로, 중계 방식, 출구 품질, 대상 웹사이트의 반환 경로에도 영향을 받습니다. 따라서 이름이 비슷한 노드라고 경로가 같은 것은 아니며, 같은 지역이라고 연결 성능이 완전히 같다는 뜻도 아닙니다.

직접 연결, 중계, IEPL 전용 회선의 차이

직접 연결은 클라이언트가 원격 서버의 공인 진입점에 바로 연결하는 방식입니다. 구조가 단순하고 서비스 측 중계에 덜 의존하지만, 국제 공용망 라우팅은 로컬 네트워크와 시간대에 따라 달라질 수 있습니다. 직접 연결이 적합한지는 지도상의 거리만이 아니라 로컬 네트워크에서 해당 진입점까지의 실제 경로를 기준으로 판단해야 합니다.

중계 회선은 먼저 가깝거나 상호 연결 조건이 적합한 진입점에 연결한 뒤, 서비스 측에서 트래픽을 원격 출구로 전달합니다. 보통 품질이 좋지 않은 공용망 구간을 피하거나, 진입점과 출구가 각각 접속과 지역 출구 역할을 맡도록 하기 위해 사용합니다. 중계라고 해서 항상 더 빠른 것은 아닙니다. 진입점이 우회하거나 전달 구간이 혼잡하거나 반환 경로가 좋지 않으면 성능이 떨어질 수 있습니다.

IEPL은 일반적으로 기업 국제 통신 환경을 위한 이더넷 전용 회선 연결을 뜻합니다. 서비스 페이지에 “IEPL 전용 회선”이라고 표시되어 있다면, 국제 구간의 특정 백본에 전용 회선 또는 전용 전송 방식이 사용된다는 의미로 이해해야 합니다. 기기에서 출발해 대상 웹사이트에 도달하는 모든 구간이 공용망에서 분리된다는 뜻은 아닙니다. 사용자와 진입점 사이, 출구와 대상 서비스 사이에는 일반 네트워크가 사용될 수 있으므로 “전용 회선” 표기만으로 실제 회선 선택을 대신할 수 없습니다.

회선 유형 경로 특징 판단할 때 더 적합한 기준
직접 연결 기기에서 원격 공용망 진입점으로 직접 접속 로컬 네트워크에서 진입점까지의 경로와 안정성 확인
중계 접속 지점으로 먼저 이동한 뒤 원격 출구로 전달 진입점 품질, 전달 경로, 대상 지역 비교
IEPL 전용 회선 일부 백본 구간에 전용 회선 전송 사용 진입점·출구·대상 서비스 성능을 종합적으로 판단

프로토콜은 클라이언트와 서버의 통신 방식을 정합니다

프로토콜은 클라이언트가 데이터를 구성하고 인증하며 전송하는 방식을 규정합니다. 회선과는 별개의 기준입니다. 같은 지역의 회선에서 여러 프로토콜을 제공할 수 있고, 하나의 프로토콜이 직접 연결이나 중계 경로에서 모두 실행될 수도 있습니다. 클라이언트가 노드에 사용된 프로토콜과 관련 전송 매개변수를 지원하지 않으면 서버 주소가 정확해도 연결을 만들 수 없습니다.

Shadowsocks

Shadowsocks는 암호화 프록시 프로토콜이며, 설정에는 일반적으로 서버·포트·비밀번호·암호화 방식이 포함됩니다. 구현이 다양하고 호환되는 클라이언트도 많지만, 양쪽이 서로 지원하는 암호화 방식을 사용해야 합니다. 인증 실패나 연결 후 트래픽 없음이 발생하면 포트를 무작정 바꾸기보다 암호화 방식과 플러그인 매개변수가 완전한지 먼저 확인해야 합니다.

VMess와 VLESS

VMess는 V2Ray 생태계에서 널리 사용되는 프로토콜로, 설정에 사용자 식별자·전송 방식·보안 매개변수가 포함됩니다. VLESS는 다른 인증 및 프로토콜 설계를 사용하며 TLS, REALITY 또는 기타 전송 계층 설정과 함께 구성되는 경우가 많습니다. 이름은 비슷하지만 서로 바꿔 쓸 수 없으므로 클라이언트는 구독에 지정된 프로토콜 유형에 따라 모든 필드를 해석해야 합니다.

Trojan

Trojan은 일반적으로 TLS 위에서 실행되며, 연결 설정에는 서버 이름·인증서 검증·비밀번호 등이 포함됩니다. 인증서 검증은 TLS 연결을 수립하는 중요한 절차입니다. 시스템 시간, 서버 이름 또는 인증서 체인에 문제가 있으면 클라이언트가 연결을 거부할 수 있습니다. 오류를 잠시 없애기 위해 인증서 검증을 끄는 것은 장기적으로 안전한 해결 방법이 아닙니다.

Hysteria2와 TUIC

Hysteria2와 TUIC는 모두 QUIC 및 UDP 전송 능력을 중요한 기반으로 삼으며, 복잡한 경로에서도 전송 효율을 유지하는 데 초점을 둡니다. 적합성은 로컬 네트워크의 UDP 지원 여부, 클라이언트 구현, 서버 매개변수에 따라 달라집니다. 현재 네트워크가 UDP를 제한한다면 이런 노드는 연결이 불안정하거나 아예 사용할 수 없으며, 이때는 서비스에서 제공하는 다른 프로토콜 노드와 비교해 볼 수 있습니다.

프로토콜 설정 확인 항목 점검 방향
Shadowsocks 암호화 방식, 비밀번호, 플러그인 매개변수 양쪽의 암호화 방식과 플러그인 지원이 일치하는지 확인
VMess 사용자 식별자, 전송 방식, 보안 매개변수 클라이언트 코어와 전체 전송 설정 점검
VLESS TLS, REALITY, 흐름 제어 및 전송 설정 VMess 설정 방식으로 대신 가져올 수 없음
Trojan 비밀번호, 서버 이름, 인증서 검증 시스템 시간, 도메인, 인증서 체인 점검
Hysteria2 UDP 도달 가능성, 인증, 혼잡 제어 매개변수 현재 네트워크가 관련 UDP 통신을 제한하지 않는지 확인
TUIC UDP 도달 가능성, 인증, QUIC 매개변수 네트워크 제한인지 다른 프로토콜과 비교
프로토콜 선택의 결론: 네트워크 환경, 클라이언트 지원 여부, 서버 설정을 떠나 항상 최적인 프로토콜은 없습니다. 구독에 사용할 수 있는 프로토콜이 이미 지정되어 있다면 전체 설정을 우선 가져오세요. 문제가 발생한 뒤에는 여러 프로토콜 노드를 비교해 장애 원인이 UDP, TLS, 클라이언트 코어 또는 회선 경로에 있는지 판단합니다.

시스템 프록시, TUN, 가상 네트워크 어댑터는 무엇을 처리할까

연결 버튼에 실행 중이라고 표시되어도 기기의 모든 트래픽이 자동으로 노드로 들어가는 것은 아닙니다. 클라이언트는 시스템 프록시, TUN 또는 플랫폼이 제공하는 VPN 인터페이스를 통해 요청을 처리해야 합니다. 처리 범위의 차이는 “브라우저는 접속되지만 게임이나 명령줄 도구에는 변화가 없다”는 현상이 발생하는 주요 원인입니다.

시스템 프록시는 앱이 프록시 설정을 따르는지에 따라 달라집니다

시스템 프록시는 운영체제에 프록시 주소를 등록합니다. 브라우저와 많은 데스크톱 앱은 이 설정을 읽어 HTTP 또는 SOCKS 요청을 클라이언트로 전달합니다. 하지만 자체 네트워크 스택이나 고정 프록시 설정을 사용하거나 직접 연결을 수립하는 앱은 시스템 프록시를 따르지 않을 수 있습니다. 이 경우 클라이언트가 정상 실행 중이어도 해당 앱은 직접 연결할 수 있습니다.

TUN 모드는 네트워크 계층에서 더 넓은 범위를 처리합니다

TUN 모드는 가상 네트워크 인터페이스로 IP 트래픽을 받은 뒤 클라이언트가 규칙에 따라 전달합니다. 시스템 프록시를 지원하지 않는 앱도 더 많이 처리할 수 있어 UDP를 다뤄야 하는 상황에도 적합합니다. 반면 추가 시스템 권한이 필요할 수 있고, 다른 가상 네트워크 어댑터나 보안 소프트웨어, 기업 네트워크 정책과 라우팅 충돌이 발생할 수 있습니다.

모바일 플랫폼의 클라이언트는 일반적으로 운영체제가 제공하는 표준 네트워크 기능인 시스템 VPN 인터페이스를 통해 트래픽을 처리합니다. 데스크톱 플랫폼은 시스템 프록시와 TUN을 함께 제공할 수 있습니다. 서로 다른 클라이언트에서 이름이 같은 “전체 모드”가 분할 라우팅 규칙만 바꾸고 처리 방식까지 자동으로 전환하지 않을 수 있으므로 실행 모드와 라우팅 모드를 함께 확인해야 합니다.

  • ✅ 브라우저는 정상인데 다른 앱에 문제가 있으면 해당 앱이 시스템 프록시를 따르는지 확인합니다.
  • ✅ 시스템 프록시를 읽지 않는 프로그램까지 처리해야 한다면 클라이언트가 TUN 또는 시스템 VPN 인터페이스를 지원하는지 확인합니다.
  • ✅ TUN 시작에 실패하면 시스템 권한, 가상 네트워크 어댑터 충돌, 남아 있는 라우팅을 점검합니다.
  • ✅ 클라이언트를 종료한 뒤에도 인터넷에 연결되지 않으면 시스템 프록시가 복원되었는지 확인합니다.
  • ❌ “노드 연결됨”을 “모든 앱의 트래픽 출구가 바뀜”과 같은 의미로 보지 않습니다.

전체 모드, 규칙 모드, 직접 연결 모드는 어떻게 선택할까

실행 모드는 “어떤 요청을 노드로 보낼 것인가”에 답합니다. 클라이언트는 보통 전체·규칙·직접 연결 모드를 제공하지만 구체적인 명칭은 조금씩 다를 수 있습니다. 모드 선택은 노드가 위치한 지역을 바꾸거나 프로토콜 비호환을 해결하지 않습니다. 규칙에 따라 매칭된 트래픽의 다음 경로를 정할 뿐입니다.

전체 모드

전체 모드는 일반적으로 클라이언트가 처리하는 모든 요청을 현재 노드로 보내는 방식입니다. 짧은 시간 동안 문제를 점검할 때 유용합니다. 규칙 모드에서는 특정 웹사이트에 접속할 수 없지만 전체 모드에서는 가능하다면 도메인이나 IP가 예상 규칙에 매칭되지 않았을 가능성이 큽니다. 단, 시스템 프록시나 TUN이 처리하지 않는 앱은 클라이언트를 우회할 수 있으므로 전체 모드가 기기의 모든 트래픽을 뜻하는 것은 아닙니다.

규칙 모드

규칙 모드는 도메인·IP·앱·네트워크 유형에 따라 노드, 직접 연결 또는 차단 경로를 결정합니다. 로컬 서비스는 직접 연결로 유지하면서 특정 출구가 필요한 요청만 노드로 보낼 수 있습니다. 규칙에 우선순위가 있다면 일반적으로 먼저 매칭된 규칙이 결과를 결정합니다. 도메인 규칙과 최종 연결 IP의 지역 판정이 다르면 예상과 다른 경로가 발생할 수도 있습니다.

직접 연결 모드

직접 연결 모드는 처리 대상 요청을 현재 네트워크 출구로 바로 보내며, 프록시 효과를 잠시 중단하거나 비교 테스트를 할 때 사용합니다. 클라이언트를 완전히 종료하는 것과 항상 같지는 않습니다. 클라이언트가 DNS를 계속 처리하거나 가상 네트워크 어댑터를 유지하거나 연결 로그를 기록할 수 있기 때문입니다. 원래 네트워크 상태를 복원하려면 클라이언트 안내에 따라 서비스를 중지하고 시스템 프록시를 확인해야 합니다.

모드 트래픽 처리 적합한 상황
전체 처리 대상 요청을 모두 현재 노드로 전달 노드와 규칙 사이의 문제를 빠르게 확인
규칙 도메인·IP·앱·유형에 따라 경로 선택 일상 사용 및 로컬·국제 트래픽 분리 처리
직접 연결 처리 대상 요청을 현재 네트워크 출구로 전달 출구 비교, 프록시 경로 일시 중단 또는 로컬 네트워크 점검

DNS, DNS 누출, 지역 판정의 관계

DNS는 도메인을 IP 주소로 변환합니다. 웹 요청이 노드를 거치는지와 도메인을 누가 해석하는지는 서로 관련 있지만 독립적인 문제입니다. 클라이언트가 연결만 처리하고 DNS는 처리하지 않으면 조회가 로컬 네트워크의 해석기로 전달될 수 있습니다. 클라이언트에서 원격 DNS, 암호화 DNS 또는 TUN 가로채기를 사용하면 조회 경로가 달라질 수 있습니다.

DNS 누출은 일반적으로 통제된 경로로 처리되어야 하는 조회 요청이 로컬 또는 예상하지 못한 다른 해석기로 전송되는 현상을 뜻합니다. 현재 네트워크가 사용하는 해석 서비스가 노출될 수 있고, 노드 출구와 맞지 않는 지역화 도메인 결과가 반환될 수도 있습니다. 다만 검사 페이지에 표시되는 해석기 위치가 사용자의 실제 위치와 반드시 같은 것은 아닙니다. 공용 해석 서비스는 애니캐스트 네트워크를 사용할 수 있으므로 표시된 장소는 참고 자료로만 봐야 합니다.

스트리밍 서비스, 검색 서비스, 콘텐츠 전송 네트워크는 출구 IP·DNS 결과·계정 지역·캐시·앱 위치 정보 등을 종합해 판정할 수 있습니다. 노드를 바꾼 뒤에도 앱에 기존 연결이나 캐시가 남아 있으면 페이지가 잠시 이전 지역 결과를 표시할 수 있습니다. 보다 안전한 방법은 재생을 중지하고 노드를 전환한 뒤 연결을 다시 만든 다음 대상 앱을 새로 열어 확인하는 것입니다.

브라우저가 자체 보안 DNS를 사용해 운영체제의 해석 설정을 우회할 수도 있으며, 기업 기기는 정책으로 해석기를 지정할 수 있습니다. 점검할 때는 클라이언트 DNS 모드, 운영체제 설정, 브라우저 설정을 함께 확인해 여러 위치에서 설정을 반복적으로 덮어쓰지 않도록 해야 합니다.

  • ✅ 클라이언트에서 현재 모드에 맞는 DNS 처리가 활성화되어 있는지 확인합니다.
  • ✅ 노드를 전환한 뒤 기존 연결을 종료하고 대상 앱을 다시 엽니다.
  • ✅ 브라우저에서 보안 DNS 서비스를 별도로 지정했는지 확인합니다.
  • ✅ 지역 결과가 이상하면 출구 IP, DNS, 계정 지역을 함께 대조합니다.
  • ❌ 검사 페이지에 표시된 해석기 데이터센터 위치를 기기의 위치로 바로 판단하지 않습니다.

플랫폼마다 클라이언트 화면이 다른 이유

Windows, macOS, Linux, iOS, Android는 네트워크 권한과 시스템 인터페이스가 서로 다르므로 클라이언트 화면도 완전히 같지 않습니다. 데스크톱 시스템은 보통 시스템 프록시·TUN·라우팅·백그라운드 서비스를 세밀하게 관리할 수 있습니다. 모바일 시스템은 시스템 VPN 인터페이스에 더 많이 의존하며 백그라운드 실행과 배터리 절전 정책의 영향을 받습니다.

Windows 클라이언트에서는 시스템 프록시가 복원되지 않거나 가상 네트워크 어댑터 드라이버가 충돌하거나 LAN 공유 설정이 일치하지 않는 문제가 흔합니다. macOS는 네트워크 확장 권한을 명확하게 안내하므로 관련 모드를 처음 활성화할 때 시스템에서 승인해야 합니다. Linux 클라이언트는 데스크톱 프록시 환경 변수, 데몬, 라우팅 권한에 대한 이해가 필요할 수 있으며 명령줄 프로그램이 데스크톱 시스템 프록시를 읽지 않을 수도 있습니다.

iOS 클라이언트는 일반적으로 시스템 VPN 설정을 통해 네트워크를 처리하며, 구독 가져오기 방식은 앱 지원 여부에 따라 달라집니다. Android 클라이언트도 시스템 VPN 인터페이스를 사용하고 앱별 분할 라우팅을 제공할 수 있습니다. 시스템 절전 정책이 백그라운드 활동을 제한하면 화면을 잠근 뒤 연결이 종료될 수 있습니다. 플랫폼이 달라도 구독·노드·프로토콜의 기본 관계는 같으며, 트래픽을 처리하는 구현 방식만 다릅니다.

플랫폼 유형 일반적인 처리 방식 주의할 점
데스크톱 시스템 시스템 프록시, TUN, 가상 네트워크 어댑터 권한, 남은 프록시 설정, 라우팅, 다른 네트워크 도구와의 충돌
모바일 시스템 시스템 VPN 인터페이스 백그라운드 제한, 절전 정책, 앱별 분할 라우팅
명령줄 환경 환경 변수, 명시적 프록시 또는 TUN 터미널 프로그램이 데스크톱 프록시 설정을 읽지 않을 수 있음

구독 가져오기부터 문제 원인 확인까지의 전체 순서

초보자가 연결 문제를 점검할 때 가장 효과적인 방법은 모든 설정을 연달아 바꾸는 것이 아니라 계층별로 하나씩 확인하는 것입니다. 한 번에 여러 변수를 바꾸면 어떤 조정이 효과를 냈는지 알 수 없습니다. 아래 순서는 설정 진입점에서 시작해 프로토콜, 회선, 트래픽 처리, DNS를 차례로 확인합니다.

  1. 구독 출처 확인.서비스 패널에서 현재 구독 링크를 복사해 지원되는 클라이언트로 가져온 뒤 구독을 직접 업데이트합니다.
  2. 노드 설정 확인.노드가 빠짐없이 표시되는지 확인하고 대상 서비스 지역에 맞는 노드를 선택합니다. 이름에 포함된 수식어만으로 결론을 내리지 않습니다.
  3. 프로토콜 지원 확인.클라이언트 코어가 노드에 사용된 Shadowsocks, VMess, Trojan, VLESS, Hysteria2 또는 TUIC와 관련 전송 매개변수를 지원하는지 확인합니다.
  4. 트래픽 처리 방식 확인.브라우저 테스트에는 시스템 프록시를 사용할 수 있습니다. 더 많은 앱을 처리해야 한다면 TUN 또는 시스템 VPN 인터페이스가 실행 중인지 확인합니다.
  5. 분할 라우팅 모드 확인.먼저 전체 모드로 비교한 다음 규칙 모드로 돌아와 매칭되지 않은 도메인·IP·앱 규칙을 찾습니다.
  6. DNS 경로 확인.클라이언트·운영체제·브라우저가 서로 다른 해석 설정을 사용하는지 확인하고 노드를 전환한 뒤 연결을 다시 만듭니다.
  7. 오류 정보 보관.클라이언트 로그에서 핸드셰이크·인증서·인증·시간 초과·UDP 오류 유형을 기록하고, 가린 설정 환경 정보를 지원 담당자에게 제공합니다.
최종 결론: 구독은 설정 목록이고, 노드는 선택 가능한 연결 설정이며, 회선은 데이터가 지나가는 경로입니다. 프로토콜은 통신 방식을 정하고, 클라이언트는 설정을 실행하며, 시스템 프록시 또는 TUN은 처리 범위를 결정합니다. 분할 라우팅 규칙은 요청을 노드로 보낼지 직접 연결할지 정하고, DNS는 도메인을 해석합니다. 이 계층에 따라 살펴보면 대부분의 용어를 올바른 위치에 놓을 수 있고, 문제를 확인할 때도 반복적인 추측에 의존하지 않아도 됩니다.