노드·프로토콜·분할 라우팅이란 무엇인지는 구독을 처음 가져올 때 가장 자주 나오는 질문입니다. 이들은 같은 층위의 개념이 아닙니다. 구독은 설정을 전달하고, 노드는 선택 가능한 연결 진입점이며, 회선은 데이터가 실제로 지나가는 네트워크 경로를 뜻합니다. 프로토콜은 클라이언트와 서버가 통신하는 방식을 정하고, 분할 라우팅 규칙은 어떤 요청이 어떤 경로를 사용할지 결정합니다. 이 개념들을 나누어 이해하면 클라이언트의 대부분의 옵션이 훨씬 명확해집니다.
초보자가 흔히 하는 실수는 연결 결과를 모두 ‘노드가 좋은가 나쁜가’로만 판단하는 것입니다. 실제 사용 경험은 로컬 네트워크, 프로토콜 지원 여부, 진입점 위치, 네트워크 간 경로, 출구 위치, DNS, 대상 웹사이트가 함께 결정합니다. 노드 이름이 같아 보여도 하부 경로가 완전히 같다는 뜻은 아니며, 프로토콜 이름이 다르다고 해서 속도에 일정한 우열이 생기는 것도 아닙니다.
구독·노드·회선은 각각 어느 계층에 있을까
구독 링크는 회선 그 자체가 아닙니다
구독 링크는 보통 서버가 생성한 설정 정보를 가리킵니다. 클라이언트가 이 주소에 접속하면 노드 이름, 서버 주소, 포트, 프로토콜 매개변수, 인증 정보, 그룹과 규칙 등의 데이터를 읽어 선택 가능한 설정으로 표시합니다. 클라이언트마다 지원하는 필드가 완전히 같지는 않으므로 같은 구독도 소프트웨어에 따라 그룹이나 옵션이 다르게 보일 수 있습니다.
구독 링크 자체가 웹 트래픽을 계속 전달하는 것은 아닙니다. 업데이트가 끝나면 클라이언트는 가져온 설정에 따라 해당 서버에 연결합니다. 즉 구독 주소는 ‘설정 가져오기’를 담당하고, 노드 주소는 ‘연결 설정’을 담당합니다. 구독 업데이트는 설정을 다시 받는 과정일 뿐, 클라이언트를 다시 설치하거나 모든 네트워크 문제를 자동으로 해결하는 작업은 아닙니다.
구독 주소에는 설정을 식별하는 접근 정보가 포함될 수 있으므로 전체 링크를 공개 페이지, 스크린샷 또는 공유 문서에 올려서는 안 됩니다. 링크가 이미 공개되었다면 로컬에서 기존 설정만 삭제하지 말고 서비스 패널에서 구독을 다시 생성하거나 교체해야 합니다. 로컬 기록을 삭제해도 이미 유출된 주소가 무효화되지는 않습니다.
노드는 진입점과 출구 설정의 조합입니다
클라이언트에서 ‘홍콩’, ‘일본’, ‘미국’ 등으로 표시되는 노드 이름은 보통 출구 지역을 나타내지만, 실제로는 서비스 제공자가 붙인 라벨일 뿐입니다. 하나의 노드 설정에는 최소한 어디에 연결할지, 어떤 프로토콜을 사용할지, 어떻게 인증할지를 알려주는 정보가 필요합니다. 서버는 트래픽을 받은 뒤 자체 네트워크 경로를 통해 대상 사이트에 접속하므로, 대상 사이트에는 일반적으로 서버의 출구 주소가 표시됩니다.
노드를 단순히 고정된 한 대의 장비로 이해해서는 안 됩니다. 실제 서비스는 진입점, 전송 구간, 출구 사이에서 트래픽을 조정하거나 여러 진입점을 하나의 출구로 모을 수 있습니다. 노드의 용도를 판단할 때는 이름의 수식어보다 출구 지역, 회선 유형, 프로토콜 호환성, 현재 네트워크 상태를 우선 확인해야 합니다.
회선은 중간 경로를 설명합니다
회선은 사용자 측에서 출구까지 데이터가 어떻게 이동하는지에 초점을 둡니다. 직접 연결, 중계, 전용 회선은 흔히 사용하는 설명이지만 프로토콜 이름은 아닙니다. 프로토콜은 통신 형식을 정하고 회선은 네트워크 경로를 정하며, 둘은 함께 구성될 수 있습니다. 같은 프로토콜이 서로 다른 회선에서 동작할 수 있고, 하나의 회선이 여러 프로토콜을 전달할 수도 있습니다.
| 용어 | 주요 역할 | 클라이언트에서 보이는 형태 | 단독으로 알 수 없는 내용 |
|---|---|---|---|
| 구독 | 설정 전달 및 업데이트 | 구독 주소, 설정 그룹 | 실제 회선 품질을 직접 보여주지는 않음 |
| 노드 | 선택 가능한 연결 진입점과 출구 설정 제공 | 지역명, 프로토콜명, 회선 라벨 | 이름만으로 하부 경로를 증명할 수 없음 |
| 프로토콜 | 클라이언트와 서버의 통신 및 인증 방식 지정 | Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC | 출구 지역과 대역폭을 단독으로 결정하지 않음 |
| 회선 | 진입점·중계·출구 사이의 네트워크 경로 설명 | 직접 연결, 중계, IEPL 전용 회선 등의 라벨 | 라벨이 실제 연결 테스트를 대신할 수 없음 |
| 분할 라우팅 | 각 요청에 프록시 또는 직접 연결 경로를 적용할지 결정 | 규칙 모드, 전체 모드, 직접 연결 모드 | 서버 자체의 장애를 해결할 수 없음 |
주요 프로토콜 이름은 어떻게 이해해야 할까
프로토콜은 클라이언트와 서버가 모두 이해해야 하는 통신 규칙입니다. 클라이언트가 특정 프로토콜을 지원하지 않으면 서버 주소, 인증 정보와 네트워크가 정상이어도 연결할 수 없습니다. 프로토콜은 전송 방식, TLS, 보안 매개변수 또는 위장 계층과 조합될 수 있으므로, 프로토콜의 대표 이름만 보고 전체 설정을 파악할 수는 없습니다.
Shadowsocks
Shadowsocks는 암호화 프록시 프로토콜로, 설정에는 보통 서버 주소, 포트, 비밀번호와 암호화 방식이 포함됩니다. 구조가 비교적 단순하고 지원하는 클라이언트도 많습니다. 암호화 방식은 서버와 일치해야 하며, 구독에서 사용하는 방식을 구형 클라이언트가 지원하지 않으면 연결할 수 없거나 가져온 뒤 사용할 수 없게 됩니다.
Shadowsocks는 클라이언트와 프록시 서버 사이의 데이터 전송 및 인증 문제를 처리합니다. 복잡한 분할 라우팅을 자동으로 제공하는 것은 아니며, 규칙은 일반적으로 클라이언트가 별도로 구현합니다. ‘Shadowsocks 노드’라고 표시되어도 프로토콜 호환성과 실제 회선은 분리해서 판단해야 합니다.
VMess 및 VLESS
VMess는 V2Ray 생태계에서 흔히 사용되며, 신원 인증, 시간 검증과 다양한 전송 조합을 포함합니다. 기기 시간이 크게 어긋나면 일부 설정은 검증 문제로 연결에 실패할 수 있습니다. VMess는 여러 전송 방식과 함께 사용할 수 있으므로, 노드에 모두 VMess라고 적혀 있어도 구체적인 네트워크 특성은 서로 다를 수 있습니다.
VLESS는 비교적 가벼운 인증 설계를 사용하며, 자체적으로 완전한 데이터 암호화 기능을 제공하지는 않습니다. 일반적으로 TLS 또는 다른 보안 전송 계층에 의존해 연결을 보호합니다. 설정의 서버 이름, 인증서 검증, 전송 방식과 경로 매개변수는 서로 맞아야 합니다. 인증서 검증을 끄면 일부 오류를 피할 수 있지만 서버 신원 확인이 약화되므로 장기적인 해결 방법으로 적합하지 않습니다.
Trojan
Trojan은 일반적으로 TLS 연결 위에서 동작하며, 설정에서 서비스 주소, 비밀번호, 서버 이름과 인증서 검증이 중요합니다. 연결 형태가 일반적인 TLS 트래픽과 비슷해 보이지만, 모든 Trojan 설정이 자동으로 더 빠르거나 안정적인 것은 아닙니다. 인증서, 도메인과 서버 이름이 일치하지 않는 경우가 흔한 연결 실패 원인입니다.
Hysteria2 및 TUIC
Hysteria2와 TUIC는 모두 UDP 기반 QUIC 전송 방식을 활용하는 경우가 많으며, 혼잡 제어, 다중화와 변동이 큰 네트워크에서의 전송 성능을 중시합니다. 지연이 높거나 패킷 손실이 발생하기 쉬운 일부 네트워크에서 더 나은 사용 경험을 제공할 수 있지만, 현재 네트워크가 UDP 전송을 안정적으로 허용해야 합니다. 일부 공용 네트워크, 기업 네트워크 또는 라우터는 UDP를 제한하므로 핸드셰이크 실패, 간헐적인 연결 끊김 또는 폴백 불가 현상이 나타날 수 있습니다.
이 두 프로토콜은 클라이언트 버전과 매개변수 호환성도 중요합니다. 프로토콜 이름이 같아도 구현 버전 차이가 크면 서로 통신하지 못할 수 있습니다. 문제가 발생하면 먼저 구독과 클라이언트를 업데이트하고 서버 요구 사항을 확인해야 하며, 다른 프로토콜의 매개변수를 임의로 복사해서는 안 됩니다.
| 프로토콜 | 설정 확인 항목 | 흔한 비호환 원인 | 판단 방법 |
|---|---|---|---|
| Shadowsocks | 암호화 방식, 비밀번호, 서버 주소 | 클라이언트가 암호화 방식을 지원하지 않음 | 먼저 암호화 방식을 확인한 뒤 회선을 테스트 |
| VMess | 인증 정보, 기기 시간, 전송 매개변수 | 매개변수 누락 또는 시간 오류 | 전체 설정과 클라이언트 로그 확인 |
| VLESS | TLS, 서버 이름, 전송 방식 | 인증서와 전송 매개변수가 일치하지 않음 | 인증서 검증을 유지하고 도메인 확인 |
| Trojan | 비밀번호, TLS, 서버 이름 | 인증서 검증 실패 | 시스템 시간, 도메인과 인증서 확인 |
| Hysteria2 | UDP 도달성, 인증 및 대역폭 매개변수 | 현재 네트워크가 UDP를 제한함 | TCP 기반 설정과 교차 테스트 |
| TUIC | UDP 도달성, 인증 및 혼잡 제어 | 클라이언트와 서버 구현이 호환되지 않음 | 먼저 클라이언트 지원 여부 확인 |
분할 라우팅 규칙은 무엇을 결정할까
분할 라우팅 규칙은 클라이언트의 경로 선택 시스템입니다. 브라우저나 앱이 요청을 보내면 클라이언트는 도메인, 대상 주소, 앱 프로세스, 네트워크 유형 또는 규칙 집합을 기준으로 해당 요청을 프록시, 직접 연결 또는 거부 중 어느 경로로 보낼지 판단합니다. 분할 라우팅은 기기 측에서 이루어지므로 같은 노드에서도 웹사이트마다 다른 경로를 사용할 수 있습니다.
규칙 모드
규칙 모드는 요청을 규칙에 따라 순서대로 매칭합니다. 일반적으로 로컬 서비스와 근거리 네트워크 리소스는 직접 연결하고, 국제 회선이 필요한 도메인은 프록시를 거치며, 광고·추적기 또는 비정상 주소에는 거부 정책을 적용합니다. 불필요한 우회를 줄이고 출구 지역 변경으로 인한 추가 인증을 방지할 수 있어 일상적인 사용에는 규칙 모드가 더 적합한 경우가 많습니다.
규칙은 브라우저 주소창의 문자열만 매칭하지 않습니다. 웹페이지는 이미지, 스크립트, API, 동영상과 서드파티 로그인 도메인도 요청합니다. 메인 사이트는 프록시를 사용하지만 연동 API가 잘못 직접 연결되면 페이지는 열려도 기능이 완전하지 않을 수 있습니다. 이런 문제를 해결할 때는 메인 도메인만 규칙에 추가하지 말고 관련 도메인도 확인해야 합니다.
전체 모드
전체 모드는 일반적으로 클라이언트가 인계받은 대부분의 트래픽을 선택한 노드로 보냅니다. 규칙 누락 여부를 짧게 확인할 때 유용합니다. 규칙 모드에서는 열리지 않지만 전체 모드에서 열리면 규칙 매칭이나 DNS가 원인일 가능성이 큽니다. 두 모드 모두 실패한다면 노드, 프로토콜, 시스템 프록시와 대상 서비스를 계속 점검해야 합니다.
전체 모드라고 해서 기기의 모든 데이터가 반드시 인계되는 것은 아닙니다. 클라이언트가 시스템 프록시, 가상 네트워크 어댑터 또는 앱 내부 프록시 중 무엇을 사용하는지에 따라 적용 범위가 달라집니다. 일부 앱은 시스템 프록시를 읽지 않고 자체 DNS나 네트워크 스택을 사용하므로 일반적인 시스템 프록시를 우회할 수도 있습니다.
직접 연결 모드
직접 연결 모드는 프록시 경로를 거치지 않으며, 근거리 네트워크 장비나 로컬 서비스를 이용하거나 문제가 프록시 설정에서 비롯되었는지 확인할 때 사용합니다. 직접 연결과 프록시가 모두 실패하면 먼저 로컬 네트워크와 대상 사이트를 확인하세요. 직접 연결은 정상인데 프록시만 실패하면 노드와 프로토콜을 점검하고, 프록시는 정상인데 직접 연결이 실패하면 로컬 네트워크 경로나 접속 지역 차이를 의심할 수 있습니다.
- ✅ 일상적인 웹 이용에서는 규칙 모드를 우선 사용해 로컬 서비스와 국제 회선이 각각 적합한 경로를 사용하도록 하세요.
- ✅ 페이지 일부 리소스가 로드되지 않을 때는 잠시 전체 모드로 전환해 규칙 누락 여부를 확인하세요.
- ✅ 라우터, 저장 장치 또는 근거리 네트워크 서비스를 이용할 때 관련 주소가 직접 연결로 유지되는지 확인하세요.
- ❌ 전체 모드를 장기간 사용하는 것을 규칙 수정의 대안으로 삼지 마세요.
- ❌ 출처와 용도를 모르는 설정 파일을 가져와 기존 규칙을 덮어쓰지 마세요.
직접 연결·중계·IEPL 전용 회선의 차이는 무엇일까
여기서 말하는 ‘직접 연결’은 회선 구조를 뜻하며, 클라이언트의 직접 연결 모드와는 다릅니다. 회선에서 직접 연결은 클라이언트가 대상 지역의 프록시 서버에 바로 연결하고 서비스 제공자가 별도로 마련한 중계 진입점을 거치지 않는 방식입니다. 구조는 단순하지만 통신사 간·지역 간 경로가 공용 네트워크의 라우팅 선택에 더 크게 좌우될 수 있어, 저녁 시간대 혼잡이나 네트워크 간 우회가 연결 품질에 바로 나타날 수 있습니다.
중계 회선은 먼저 가깝거나 도달하기 쉬운 진입점에 연결한 다음, 진입점이 대상 출구로 트래픽을 전달하는 방식입니다. 이를 통해 사용자 측에서 진입점까지와 진입점에서 출구까지를 나누어 최적화할 수 있습니다. 중계는 일부 불안정한 공용 라우팅을 피하는 데 도움이 될 수 있지만 유지 관리가 필요한 구간이 하나 더 생깁니다. 진입점은 정상이어도 출구에 문제가 있거나, 진입점과 출구 사이에서 장애가 발생하면 노드를 사용할 수 없게 됩니다.
IEPL은 국제 이더넷 전용 회선을 뜻하는 대표적인 약어로, 원래 통신사가 제공하는 지점 간 기업 네트워크 연결을 설명할 때 사용됩니다. 구독 서비스에서 ‘IEPL 전용 회선’은 보통 진입점과 출구 사이에 전용 회선 또는 이에 준하는 통제된 전송 경로를 사용한다는 의미입니다. 다만 사용자에서 진입점까지의 구간은 여전히 로컬 접속 네트워크를 거쳐야 합니다. 사용자 기기에서 대상 사이트까지의 전체 경로가 공용 네트워크에서 완전히 분리된다는 뜻도 아니며, 어떤 시간대에도 로컬 네트워크의 영향을 받지 않는다는 의미도 아닙니다.
따라서 회선 라벨은 구조를 이해하는 데 도움을 줄 뿐 실제 판단을 대신할 수 없습니다. 자신의 네트워크에 맞는 진입점을 선택하고, 지속 연결, 웹페이지 최초 로딩, 동영상 버퍼링과 파일 전송이 안정적인지 확인한 뒤 다른 회선과 비교하는 것이 더 안전합니다. 한 번의 짧은 테스트는 당시 상태만 보여줄 뿐 장기적인 결론으로 이어지기에는 부족합니다.
| 회선 유형 | 기본 경로 | 주요 특징 | 점검할 항목 |
|---|---|---|---|
| 직접 연결 회선 | 사용자 측에서 출구로 직접 연결 | 구조가 단순하고 공용 네트워크 라우팅에 더 크게 의존 | 네트워크 간 우회, 출구 도달성, 로컬 네트워크 |
| 중계 회선 | 사용자 측에서 진입점에 연결한 뒤 출구로 전달 | 접속 구간과 국제 구간을 나누어 최적화 가능 | 진입점 상태, 진입점에서 출구까지의 전달 경로 |
| IEPL 전용 회선 | 진입점에 접속한 뒤 통제된 전송 경로로 출구에 연결 | 중간 경로를 일반적으로 더 세밀하게 제어 가능 | 사용자에서 진입점까지의 로컬 접속과 출구 상태 |
DNS 누수와 도메인 확인은 왜 결과에 영향을 줄까
사용자가 도메인을 입력하면 기기는 먼저 도메인을 네트워크 주소로 변환해야 합니다. 이 작업을 DNS가 처리합니다. 웹 트래픽은 프록시를 거치지만 도메인 조회는 로컬 네트워크의 DNS 서버가 처리하면 DNS 누수가 발생할 수 있습니다. 이 경우 로컬 DNS 제공자가 조회한 도메인을 확인할 수 있고, 변환 결과가 프록시 출구 지역과 일치하지 않을 수도 있습니다.
DNS 누수는 반드시 ‘전혀 열리지 않는’ 형태로 나타나지는 않습니다. 더 흔한 현상은 적합하지 않은 콘텐츠 전송 노드로 연결되거나, 웹사이트의 지역 판단이 서로 다르거나, 메인 페이지는 열리지만 API가 실패하거나, 규칙 모드에서 판단이 반복되는 것입니다. 클라이언트는 보통 시스템 DNS, 프록시 DNS, 암호화 DNS 또는 가상 매핑 같은 방식을 제공합니다. 방식에 따라 호환성과 분할 라우팅의 정확도가 달라집니다.
규칙이 도메인 정보를 필요로 할 때는 DNS 처리 순서가 특히 중요합니다. 앱이 먼저 도메인을 주소로 변환하고 클라이언트가 대상 주소만 받으면 도메인 기반 규칙이 적용되지 않을 수 있습니다. 가상 네트워크 어댑터 모드를 지원하는 클라이언트는 트래픽과 DNS를 더 완전하게 인계할 수 있지만, 보안 소프트웨어, 기업 네트워크 정책 또는 다른 네트워크 도구와 충돌하기도 쉽습니다.
DNS 문제를 확인할 때 출구 주소만 보지 마세요. DNS 서버의 지역, 브라우저에서 별도의 암호화 DNS를 사용하는지, 클라이언트가 DNS를 인계하는지, 규칙에 DNS 요청을 잘못 직접 연결하는 항목이 있는지를 함께 확인해야 합니다. 변경 후에는 시스템과 브라우저의 DNS 캐시를 비우고 연결을 다시 설정하세요.
플랫폼별 구독 가져오기와 클라이언트 업데이트 방법
구독 가져오기 절차는 대체로 같습니다. 서비스 패널에서 구독 주소를 가져와 호환되는 클라이언트에 원격 설정으로 추가하고, 클라이언트가 노드를 불러올 때까지 기다린 다음 그룹, 노드와 실행 모드를 선택합니다. 실제로 오류가 생기기 쉬운 부분은 ‘붙여넣기’가 아니라 클라이언트가 구독 형식, 프로토콜과 전체 매개변수를 지원하는지 여부입니다.
데스크톱 플랫폼
Windows와 Linux 클라이언트는 일반적으로 시스템 프록시, 가상 네트워크 어댑터, 라우팅 규칙과 연결 로그를 폭넓게 제공합니다. 시스템 프록시는 프록시 설정을 읽는 앱에만 영향을 주며, 가상 네트워크 어댑터 모드는 더 많은 트래픽을 인계할 수 있지만 해당 시스템 권한이 필요합니다. 특정 앱이 프록시를 사용하지 않을 때는 노드가 작동하지 않는다고 단정하기 전에 현재 트래픽 인계 방식을 확인해야 합니다.
macOS 클라이언트도 시스템 프록시와 가상 네트워크 어댑터 모드를 제공할 수 있습니다. 시스템 업데이트, 보안 정책과 네트워크 확장 권한에 따라 가상 네트워크 어댑터가 시작되지 않을 수 있습니다. 클라이언트에 ‘연결됨’이라고 표시되어도 로컬 서비스가 실행 중이라는 뜻일 뿐 원격 노드의 핸드셰이크 성공을 보장하지는 않습니다. 연결 로그나 실제 접속 결과를 확인해야 합니다.
모바일 플랫폼
Android 클라이언트는 일반적으로 시스템이 제공하는 VPN 인터페이스를 통해 기기 트래픽을 인계하며, 앱별로 프록시 경유 여부를 정할 수 있습니다. 앱 분할과 도메인 분할은 서로 다른 두 기준입니다. 전자는 어떤 앱이 클라이언트에 들어올지를 정하고, 후자는 들어온 요청에 어떤 경로를 적용할지 결정합니다. 두 설정이 충돌하면 브라우저는 정상인데 특정 앱만 연결되지 않을 수 있습니다.
Apple 모바일 플랫폼의 클라이언트도 시스템 네트워크 확장에 의존합니다. 백그라운드 정책, 배터리 절약 상태와 네트워크 전환이 연결 유지에 영향을 줄 수 있습니다. Wi-Fi에서 모바일 네트워크로 전환한 뒤 연결된 것처럼 보이지만 요청이 멈춘다면 먼저 다시 연결한 다음 구독 업데이트가 필요한지 판단하세요.
- 서비스 패널에서 현재 클라이언트에 맞는 구독 주소를 복사하세요. 채팅 기록의 스크린샷을 보고 직접 입력하지 마세요.
- 클라이언트에 원격 설정을 추가하고 가져온 결과에 노드와 정책 그룹이 표시되는지 확인하세요.
- 클라이언트와 호환되는 노드를 선택하고, 첫 테스트에서는 기본 프로토콜 매개변수를 유지하세요.
- 규칙 모드를 활성화하고 일반 웹페이지를 열어 기본 연결을 확인한 다음 특정 앱을 테스트하세요.
- 규칙 문제를 확인해야 한다면 잠시 전체 모드로 전환해 비교한 뒤 테스트가 끝나면 규칙 모드로 되돌리세요.
- 서버 설정이 변경되면 구독을 업데이트하세요. 업데이트에 실패하면 구독 주소가 완전한지, 네트워크에서 설정 서버에 접속할 수 있는지 확인하세요.
연결 실패 시 계층별로 점검하는 방법
효율적인 문제 해결은 모든 옵션을 연속해서 바꾸는 것이 아니라 비교를 통해 이루어집니다. 한 번에 하나의 변수만 바꿔야 문제가 어느 계층에서 발생했는지 알 수 있습니다. 먼저 로컬 네트워크를 확인한 뒤 구독과 클라이언트, 노드, 프로토콜, 회선, 분할 라우팅과 DNS를 차례로 점검하세요. 클라이언트, 노드와 모드를 동시에 바꾸면 연결이 복구되어도 실제 원인을 알 수 없습니다.
- ✅ 프록시를 끈 뒤 로컬 네트워크로 자주 사용하는 서비스에 정상적으로 접속할 수 있는지 확인하세요.
- ✅ 구독을 업데이트하고 노드 목록이 완전한지 확인하며 클라이언트에 표시되는 가져오기 오류를 살펴보세요.
- ✅ 클라이언트가 노드에 사용된 프로토콜, 암호화 방식과 전송 매개변수를 지원하는지 확인하세요.
- ✅ 같은 클라이언트에서 다른 회선으로 전환해 개별 노드 문제인지 전체 설정 문제인지 구분하세요.
- ✅ 규칙 모드와 전체 모드를 비교해 규칙 누락 여부를 판단하세요.
- ✅ 시스템 시간, 인증서 검증, DNS 인계와 가상 네트워크 어댑터 권한을 확인하세요.
- ✅ 클라이언트 로그에서 DNS, 핸드셰이크, 시간 초과 또는 인증서 오류를 읽고 다음 조치를 결정하세요.
- ❌ 오류를 없애기 위해 인증서 검증을 장기간 끄지 마세요.
- ❌ 용도를 모르는 상태에서 혼잡 제어, 전송 경로 또는 하부 라우팅 매개변수를 수정하지 마세요.
로그의 ‘DNS 조회 실패’는 일반적으로 DNS 또는 도메인 설정을 가리킵니다. ‘연결 시간 초과’는 네트워크 도달 불가, 포트 제한 또는 회선 이상과 관련될 수 있습니다. ‘인증서 오류’가 발생하면 기기 시간, 서버 이름과 인증서 체인을 확인하세요. ‘인증 실패’는 구독 만료 여부, 설정 완전성, 클라이언트가 인증 필드를 잘못 수정했는지를 점검해야 합니다.
한 노드가 한 네트워크에서는 작동하지만 다른 네트워크에서는 작동하지 않는다면 통신사 경로, UDP 지원 여부와 로컬 기기 설정을 중점적으로 비교하세요. 같은 클라이언트에서 모든 노드가 실패하지만 동일한 구독이 다른 호환 클라이언트에서 작동한다면 클라이언트 버전, 권한 또는 트래픽 인계 방식이 원인일 가능성이 큽니다. 모든 클라이언트에서 구독 업데이트가 되지 않는다면 먼저 구독 주소와 설정 서버의 도달 가능성을 확인하세요.