네트워크 가속 도구를 처음 사용하면 VPN 구독, 노드, 프로토콜, 분할 라우팅과 글로벌 모드가 클라이언트에 한꺼번에 나타나는 경우가 많습니다. 하지만 이들은 같은 계층의 설정이 아닙니다. 구독은 설정을 전달하고, 노드는 선택 가능한 연결 입구를 의미하며, 프로토콜은 클라이언트와 서버의 통신 방식을 정합니다. 회선은 데이터가 통과하는 네트워크 경로를 설명하고, 분할 라우팅 모드는 어떤 요청을 프록시로 보낼지 결정합니다. 이 계층을 먼저 나누어 이해하면 클라이언트의 대부분의 옵션이 훨씬 쉬워집니다.
일상적인 대화에서 “VPN”은 네트워크 가속 서비스를 통칭하는 말로 자주 쓰이지만, 클라이언트가 실제로 사용하는 기술이 전통적인 VPN 프로토콜이라는 뜻은 아닙니다. 일부 도구는 시스템 VPN 인터페이스로 가상 네트워크 어댑터를 만든 뒤 트래픽을 Shadowsocks, VMess, Trojan, VLESS, Hysteria2 또는 TUIC 등의 프로토콜로 처리합니다. 따라서 시스템 상태 표시줄에 VPN 표시가 나타난다는 사실만으로는 클라이언트가 시스템 네트워크 제어 인터페이스를 활성화했다는 점만 알 수 있으며, 하위 프로토콜까지 판단할 수는 없습니다.
구독, 구독 링크와 설정 파일은 무엇인가
구독은 서버에서 관리하는 설정 목록이라고 이해하면 됩니다. 일반적으로 노드 이름, 서버 주소, 포트, 프로토콜 매개변수, 인증 정보와 클라이언트가 인식할 수 있는 기타 필드를 포함합니다. 구독을 호환 클라이언트에 가져오면 클라이언트가 목록을 해석해 노드 목록을 만들므로 항목을 하나씩 직접 입력할 필요가 없습니다.
구독 링크는 이 목록을 가져오는 주소입니다. 일반적인 홍보 페이지가 아니라 계정 식별 정보가 포함된 설정 진입점입니다. 링크를 얻은 사람은 누구나 그 안의 노드 설정을 읽을 수 있으므로 공개 채팅방, 스크린샷 또는 공개 문서에 공유해서는 안 됩니다. 링크가 노출된 것으로 의심되면 로컬 클라이언트에서 노드만 삭제하지 말고 서비스 패널에서 구독을 재설정해야 합니다.
설정 파일은 구독 내용을 로컬에 저장한 정적 사본입니다. 일반적으로 텍스트 설정과 구조화된 설정 형태가 있습니다. 파일을 직접 가져오면 오프라인으로 이전하기에 적합하지만 서버의 후속 변경 사항이 자동으로 반영되지는 않습니다. 반면 구독 링크는 클라이언트가 직접 업데이트할 수 있습니다. 노드가 추가되거나 접속 지점 또는 규칙이 변경된 경우에는 클라이언트를 다시 설치하기보다 구독을 새로 고치는 편이 효과적입니다.
구독을 가져올 때 클라이언트에서 실제로 하는 일
- 클라이언트가 구독 주소에 요청을 보내 설정 내용을 다운로드합니다.
- 프로토콜, 서버 접속 지점, 인증 필드와 노드 이름을 해석합니다.
- 여러 노드를 선택 가능한 프록시 그룹 또는 목록으로 정리합니다.
- 로컬 규칙에 따라 기본 노드, 업데이트 방식과 트래픽 처리 모드를 결정합니다.
- 연결할 때 로컬 프록시 포트 또는 가상 네트워크 어댑터를 만들고, 조건에 맞는 요청을 선택한 노드로 전달합니다.
가져오기에 성공했다고 연결이 이미 적용된 것은 아닙니다. 구독은 클라이언트가 설정을 읽었다는 사실만 보여 줍니다. 사용 가능한 노드를 선택하고 시스템 프록시 또는 가상 네트워크 어댑터를 활성화한 다음 실제 접속과 DNS 검사를 통해 트래픽 경로를 확인해야 합니다. 클라이언트에 구독 업데이트 성공이 표시되는데도 웹 페이지가 기존 네트워크로 연결된다면 같은 링크를 반복해서 가져오기보다 모드, 프록시 그룹 선택과 시스템 권한을 먼저 확인해야 합니다.
노드, 서버와 회선은 같은 개념이 아닙니다
노드는 클라이언트에서 선택할 수 있는 연결 설정입니다. 하나의 서버에 직접 대응할 수도 있고, 특정 접속 지점이나 부하 분산 주소 또는 회선 조합일 수도 있습니다. 노드 이름에 포함된 국가와 도시는 일반적으로 출구 위치나 회선 용도를 나타내며, 서버 장비의 실제 배치 세부 정보와 반드시 일치하지는 않습니다.
서버는 연결을 처리하는 컴퓨팅 자원으로, 인증·전달 또는 프로토콜 종료를 담당합니다. 일반 사용자는 서버 내부 구조까지 알 필요가 없으며, 노드가 목적 지역과 현재 네트워크, 사용하는 애플리케이션에 적합한지만 확인하면 됩니다.
회선은 로컬에서 접속 지점과 출구까지 데이터가 거치는 네트워크 경로를 강조하는 개념입니다. 두 노드의 출구 지역이 같더라도 접속 지점, 통신사 간 연동 또는 중간 전송 방식이 다르면 실제 사용 경험이 달라질 수 있습니다. 반대로 하나의 회선이 여러 노드 이름으로 제공되면서 프로토콜이나 용도가 달라질 수도 있습니다.
| 회선 유형 | 연결 경로 | 주요 특징 | 선택 기준 |
|---|---|---|---|
| 직결 | 클라이언트가 해외 접속 지점에 직접 연결 | 경로가 단순하며 로컬 네트워크와 국제 연동 품질의 영향을 크게 받음 | 현재 접속 네트워크가 접속 지점에 안정적으로 도달하는지 확인 |
| 중계 | 가까운 접속 지점에 먼저 연결한 뒤 출구로 전달 | 네트워크 간 경로를 조정할 수 있지만 전달 단계가 하나 더 추가됨 | 접속 지점 품질, 전달 경로와 출구 용도를 확인 |
| IEPL 전용 회선 | 국제 이더넷 전용 회선으로 지정 구간을 전송 | 일반 공용망 직결과는 다른 방식으로 경로를 관리 | 서비스 제공자가 표시한 실제 접속 범위를 확인 |
직결이 항상 중계보다 빠른 것은 아니며, 중계가 반드시 직결보다 우수한 것도 아닙니다. 적합한 경로인지는 로컬 통신사, 접속 지역, 출구 방향과 당시 네트워크 상태에 따라 달라집니다. 중계의 가치는 모든 혼잡을 없애는 데 있는 것이 아니라 경로의 일부를 다시 구성하는 데 있습니다. IEPL은 국제 이더넷 전용 회선 서비스의 업계 명칭이지만, 클라이언트의 “IEPL” 표시는 서비스 설명과 함께 이해해야 합니다. 전용 회선이 전체 경로 중 특정 구간만 담당할 수도 있기 때문입니다.
초보자가 노드를 선택할 때는 클라이언트에 표시되는 지연 시간만 봐서는 안 됩니다. 지연 시간은 보통 한 번의 측정 결과라서 접속 지점에 도달할 수 있는지를 보여 줄 뿐, 웹 페이지 로딩, 지속적인 데이터 전송 또는 특정 애플리케이션의 성능을 완전히 나타내지는 못합니다. 먼저 목적 지역으로 필터링한 다음 실제 사용 환경에서 연결 수립, 페이지 응답과 지속 전송이 안정적인지 비교하는 방법이 더 안전합니다.
주요 프로토콜: Shadowsocks, VMess, Trojan과 VLESS
프로토콜은 클라이언트와 서버가 데이터를 캡슐화하고 인증하며 전송하는 방식을 정합니다. 프로토콜 이름이 회선 품질을 의미하지는 않습니다. 같은 프로토콜이 서로 다른 회선에서 실행될 수 있고, 하나의 회선이 여러 프로토콜을 제공할 수도 있습니다. 선택할 때는 클라이언트 호환성, 현재 네트워크가 해당 전송 방식을 지원하는지, 그리고 서버에서 제공한 설정을 함께 고려해야 합니다.
Shadowsocks
Shadowsocks는 암호화 프록시 프로토콜로, 구조가 비교적 단순하고 클라이언트 생태계가 성숙해 있습니다. 사전 공유 키로 암호화와 인증을 수행하며, 다양한 클라이언트와의 호환성이 필요한 환경에 주로 적합합니다. 암호화 방식은 임의로 섞어 사용할 수 없고 서버와 클라이언트가 동일한 매개변수를 사용해야 합니다. 구독을 가져온 뒤 암호화 방식을 직접 변경하면 포트에는 도달하지만 인증에 실패하는 경우가 많습니다.
VMess와 VLESS
VMess는 식별자와 프로토콜 필드를 사용해 클라이언트와 서버 간 통신을 수행하며, WebSocket, TCP 또는 다른 전송 방식과 함께 구성되는 경우가 많습니다. VLESS는 가벼운 인증에 초점을 두며 자체적으로 완전한 전송 암호화를 제공하지 않으므로 일반적으로 TLS, REALITY 또는 보호된 하위 채널과 함께 사용해야 합니다. VLESS 노드를 확인할 때는 프로토콜 이름뿐 아니라 전송 방식, 보안 계층, 서버 이름과 클라이언트 코어의 호환성도 확인해야 합니다.
VMess와 VLESS는 이름이 비슷하지만 설정 필드를 그대로 바꿔 쓸 수는 없습니다. VLESS 노드를 VMess 방식으로 직접 입력하거나 TLS 관련 매개변수를 빠뜨리면 연결에 실패합니다. 구독으로 가져오는 이유 중 하나는 이런 연관 필드를 수동으로 옮길 때 발생하는 오류를 줄이는 데 있습니다.
Trojan
Trojan은 일반적으로 TLS 위에서 실행되며 비밀번호로 인증합니다. 클라이언트는 서버 이름, 인증서 검증과 전송 매개변수를 올바르게 처리해야 합니다. 인증서 오류가 발생했을 때 “인증서 검증 건너뛰기”를 장기적인 해결책으로 삼아서는 안 됩니다. 먼저 시스템 시간, 서버 이름, 구독 만료 여부와 클라이언트 코어가 해당 설정을 지원하는지 확인해야 합니다.
Hysteria2와 TUIC
Hysteria2와 TUIC는 모두 UDP와 QUIC 기반 전송을 중시하며, 패킷 손실이나 변동이 있는 환경에서 각자의 혼잡 제어와 다중화 메커니즘으로 전송 방식을 개선할 수 있습니다. 다만 현재 네트워크가 UDP를 지원해야 하며, 일부 공용 네트워크·기업 네트워크 또는 라우팅 정책은 UDP를 제한할 수 있습니다. 이 경우 노드 설정이 올바르게 보이더라도 핸드셰이크가 오랫동안 완료되지 않을 수 있습니다. TCP 기반 호환 노드로 전환하는 것이 진단 단계로 더 적합한 경우가 많습니다.
글로벌 모드, 규칙 모드와 직결 모드 선택 방법
클라이언트의 “모드”는 트래픽을 어떻게 분배할지 결정합니다. 노드 선택과는 별개의 기능입니다. 노드는 프록시 대상 트래픽을 어디로 보낼지 정하고, 모드는 어떤 트래픽을 그곳으로 보낼지 결정합니다. 해외 노드를 선택했다고 해서 기기의 모든 요청이 자동으로 해당 노드를 거치는 것은 아닙니다.
| 모드 | 처리 방식 | 적합한 상황 | 일반적인 문제 |
|---|---|---|---|
| 규칙 모드 | 도메인, 주소 또는 애플리케이션 규칙에 따라 프록시와 직결을 결정 | 일상적인 사용, 로컬 서비스는 기존 경로 유지 | 규칙 미적용, 오래된 규칙 또는 순서 충돌 |
| 글로벌 모드 | 제어 가능한 요청을 모두 선택한 프록시로 전달 | 규칙 때문에 접속이 실패하는지 일시적으로 확인 | 로컬 서비스의 우회 경로 발생, 내부 네트워크 리소스 접속 불가 |
| 직결 모드 | 요청이 프록시 노드를 거치지 않음 | 프록시를 일시 중지하거나 기존 네트워크 성능 비교 | 노드에 연결됐다고 생각했지만 실제로는 사용하지 않음 |
규칙 모드는 일반적인 사용에 더 적합한 경우가 많습니다. 클라이언트는 도메인, IP 주소, 지역별 목록 또는 애플리케이션 프로세스를 규칙과 대조한 뒤 요청을 프록시, 직결 또는 차단 정책으로 보냅니다. 규칙에는 순서가 있습니다. 구체적인 규칙을 일반적인 기본 규칙보다 앞에 두어야 하며, 그렇지 않으면 앞의 포괄적인 규칙이 요청을 먼저 처리할 수 있습니다.
글로벌 모드는 모든 상황에서 계속 켜 두기보다 진단용으로 사용하는 편이 적합합니다. 규칙 모드에서 특정 웹사이트가 실패했지만 글로벌 모드로 전환한 뒤 정상화된다면, 문제는 노드 자체보다 규칙 매칭, DNS 해석 또는 프록시 그룹 선택에 있을 가능성이 큽니다. 글로벌 모드는 로컬 웹사이트, 로컬 네트워크 기기와 시스템 서비스에도 우회 경로를 적용할 수 있으므로 진단이 끝나면 필요에 따라 규칙 모드로 되돌려야 합니다.
직결 모드에서는 트래픽이 기존 네트워크 경로를 사용합니다. 프록시 사용 전후의 차이를 비교하거나 클라이언트를 종료하지 않고 전달 기능을 잠시 중지할 때 사용할 수 있습니다. 다만 일부 클라이언트의 “직결”은 규칙 결정에만 영향을 주며 가상 네트워크 어댑터는 계속 활성화될 수 있습니다. 완전히 네트워크 제어가 중지됐는지는 시스템 프록시, 가상 네트워크 어댑터와 클라이언트 실행 상태를 함께 확인해야 합니다.
분할 라우팅 규칙에는 어떤 조건이 포함되는가
- 도메인 접미사: 특정 사이트와 하위 도메인에 지정된 정책을 적용합니다.
- 전체 도메인: 특정 호스트만 일치시키므로 세밀한 적용에 적합합니다.
- IP 주소 범위: 대상 주소에 따라 프록시 또는 직결을 결정합니다.
- 애플리케이션 프로세스: 지정한 소프트웨어만 특정 프록시 그룹을 사용하게 합니다.
- 지역 규칙 집합: 관리된 도메인 또는 주소 목록을 기준으로 분류합니다.
- 기본 규칙: 앞선 조건과 일치하지 않은 모든 요청을 처리합니다.
분할 라우팅은 웹 주소만 확인하지 않습니다. 하나의 페이지가 메인 사이트, 이미지 도메인, API 도메인과 콘텐츠 전송 도메인에 동시에 요청할 수 있습니다. 이 요청들이 서로 다른 출구로 나뉘면 페이지는 열리지만 이미지가 표시되지 않거나, 로그인 반복 또는 인증 코드 오류가 발생할 수 있습니다. 문제를 해결할 때는 메인 도메인에 예외만 추가하지 말고 클라이언트 연결 기록에서 관련 도메인이 각각 어떤 규칙과 일치했는지 확인해야 합니다.
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN,local.example,DIRECT
GEOIP,LAN,DIRECT
MATCH,PROXY이 예시 규칙은 지정한 도메인 접미사를 프록시로 보내고, 로컬 도메인과 로컬 네트워크 주소는 직결로 유지하며, 나머지 요청은 기본 정책으로 처리한다는 의미입니다. 클라이언트마다 문법, 규칙 이름과 지원 범위가 완전히 같지는 않으므로 하나의 설정을 모든 소프트웨어에 그대로 복사할 수 없습니다. 수정하기 전에 원래 설정을 백업하고, 클라이언트 문서에서 지원하는 필드를 기준으로 작업해야 합니다.
시스템 프록시, TUN 모드와 가상 네트워크 어댑터의 차이
시스템 프록시는 운영체제에 HTTP 또는 SOCKS 프록시 주소를 등록하는 기능입니다. 시스템 프록시 설정을 따르는 브라우저와 애플리케이션은 요청을 클라이언트로 전달하지만, 일부 소프트웨어는 시스템 프록시를 무시하거나 자체 네트워크 스택을 사용하거나 UDP 요청을 직접 보낼 수 있습니다. 따라서 시스템 프록시를 켠 뒤에도 제어되지 않는 애플리케이션 트래픽이 남을 수 있습니다.
TUN 모드는 일반적으로 가상 네트워크 어댑터로 IP 계층 트래픽을 받은 뒤 클라이언트가 규칙에 따라 전달합니다. 시스템 프록시를 지원하지 않는 애플리케이션도 더 폭넓게 처리할 수 있고 UDP에도 적합하지만, 더 높은 시스템 권한이 필요하며 다른 네트워크 필터링 소프트웨어, 기업 보안 정책 또는 기존 가상 네트워크 어댑터와 충돌할 수 있습니다.
가상 네트워크 어댑터는 트래픽이 클라이언트로 들어오는 방식일 뿐, 모든 트래픽이 반드시 원격 노드를 거친다는 뜻은 아닙니다. 클라이언트는 TUN 모드에서도 직결, 프록시와 차단 규칙을 적용할 수 있습니다. 시스템에 VPN 표시가 나타나더라도 상태 아이콘만으로 출구를 판단하지 말고 클라이언트 연결 기록에서 규칙 적용 결과를 확인해야 합니다.
DNS 누출이란 무엇이며 분할 라우팅에 어떤 영향을 주는가
도메인에 접속하기 전에 기기는 일반적으로 DNS를 통해 도메인을 주소로 변환합니다. 웹 트래픽은 프록시를 거치지만 DNS 조회가 기존 네트워크의 리졸버로 전송되면 DNS 누출이 발생할 수 있습니다. 이로 인해 조회 중인 도메인 정보가 노출될 수 있고, 현재 출구에 적합하지 않은 해석 결과가 반환되어 연결 경로 우회, 주소 접속 불가 또는 규칙 판단 오류가 발생할 수도 있습니다.
규칙 모드는 특히 DNS 설계에 의존합니다. 일부 클라이언트는 먼저 도메인을 해석한 뒤 IP 규칙으로 매칭하고, 일부는 도메인 정보를 유지한 채 도메인 규칙을 적용하며, 일부 TUN 구현은 가상 주소 매핑을 사용합니다. “DNS 활성화” 여부만 확인해서는 안 됩니다. 누가 DNS 요청을 보내는지, 어떤 인터페이스를 거치는지, 해석 결과가 프록시 출구와 일치하는지도 확인해야 합니다.
DNS 경로를 확인하는 실용적인 순서
- 클라이언트에서 내장 DNS 또는 원격 해석 기능을 활성화했는지 확인합니다.
- 시스템에 다른 네트워크 도구가 작성한 DNS 설정이 남아 있는지 확인합니다.
- 규칙 모드와 글로벌 모드에서 동일한 도메인을 각각 테스트합니다.
- 시스템과 브라우저의 DNS 캐시를 삭제한 뒤 다시 연결합니다.
- 브라우저에서 클라이언트 정책과 다른 암호화 DNS를 별도로 활성화했는지 확인합니다.
- 연결 기록에서 DNS 요청과 대상 연결이 예상한 정책과 일치했는지 확인합니다.
브라우저의 암호화 DNS 자체가 문제는 아니지만, 클라이언트의 분할 라우팅 DNS를 우회하면 두 가지 해석 결과가 생길 수 있습니다. 문제를 해결할 때는 먼저 브라우저가 시스템 설정을 따르도록 임시 설정해 클라이언트 경로가 정상인지 확인한 뒤 브라우저 자체 해석 방식을 다시 사용할지 결정할 수 있습니다. 핵심은 도메인 해석과 후속 연결이 일관되고 설명 가능한 출구 정책을 사용하는 것입니다.
플랫폼별 클라이언트가 서로 다르게 보이는 이유
Windows 클라이언트는 일반적으로 시스템 프록시와 TUN 모드를 함께 제공합니다. 시스템 프록시는 설정이 간단하지만 모든 애플리케이션이 따르는 것은 아닙니다. TUN은 더 폭넓게 적용되지만 가상 네트워크 어댑터 드라이버와 관리자 권한이 필요합니다. 활성화 후 네트워크가 끊기면 가상 네트워크 어댑터, 라우팅 테이블, DNS 설정과 다른 네트워크 필터링 프로그램의 충돌 여부를 확인해야 합니다.
macOS 클라이언트는 시스템 네트워크 확장 또는 VPN 설정을 통해 트래픽을 제어하는 경우가 많습니다. 처음 활성화할 때는 시스템 설정에서 권한을 승인해야 합니다. 시스템 업데이트 후 클라이언트는 열리지만 터널을 만들 수 없다면 구독을 다시 설치하기보다 네트워크 확장에 여전히 권한이 있는지 확인해야 합니다. Apple 칩과 Intel 기기는 서로 다른 빌드 버전을 사용할 수도 있으므로 다운로드할 때 클라이언트의 릴리스 안내를 기준으로 선택해야 합니다.
Android 클라이언트는 일반적으로 시스템 VPN 서비스를 호출해 로컬 터널을 만들며, 애플리케이션별로 프록시 사용 여부를 정할 수 있습니다. 배터리 절약 정책이 백그라운드에서 클라이언트가 계속 실행되는 것을 제한하면 화면을 잠근 뒤 연결이 끊길 수 있습니다. 문제를 해결할 때는 백그라운드 실행 권한, 데이터 절약 설정과 애플리케이션별 분할 라우팅 목록을 확인해야 합니다.
iOS와 iPadOS 클라이언트는 시스템 네트워크 확장 메커니즘의 제약을 받으며 설정은 일반적으로 특정 애플리케이션 안에 저장됩니다. 같은 구독을 가져와도 클라이언트마다 규칙 집합, 스크립트와 프로토콜 코어 지원이 다를 수 있습니다. 데스크톱에서는 사용할 수 있는 노드를 모바일에서 가져올 수 없다면 구독이 만료됐다고 단정하기보다 프로토콜과 전송 방식 지원 여부를 먼저 확인해야 합니다.
Linux 환경에서는 데스크톱 클라이언트를 사용할 수도 있고 명령줄 코어를 실행할 수도 있습니다. 데스크톱 애플리케이션은 시스템 프록시로 일반적인 소프트웨어의 트래픽을 제어할 수 있지만, 명령줄 프로그램은 환경 변수를 별도로 설정하거나 TUN과 라우팅 규칙으로 통합 처리해야 할 수 있습니다. 문제를 해결할 때는 “코어가 실행 중인지”, “로컬 포트가 수신 대기 중인지”, “애플리케이션이 프록시를 사용하고 있는지”를 구분해야 합니다.
가져오기부터 연결까지 전체 점검 절차
초보자는 여러 문제를 하나로 묶기 쉽습니다. 구독 다운로드 실패, 노드 핸드셰이크 실패, 규칙 미적용, 애플리케이션의 시스템 프록시 미사용이 모두 “열리지 않는다”는 증상으로 나타날 수 있습니다. 계층별로 점검하면 불필요한 작업을 줄일 수 있습니다.
- 구독 확인: 링크가 서비스 패널에서 발급된 것인지, 클라이언트가 정상적으로 업데이트되는지, 노드 목록이 예상대로 변경되는지 확인합니다.
- 호환성 확인: 클라이언트 코어가 노드에 사용된 프로토콜, 전송 방식과 보안 계층을 지원하는지 확인합니다.
- 노드 확인: 먼저 용도가 분명한 노드를 선택하고 핸드셰이크 또는 연결 로그를 확인합니다. 지연 시간 표시만으로 판단하지 마세요.
- 트래픽 제어 확인: 시스템 프록시 또는 TUN이 활성화되어 있고 대상 애플리케이션이 실제로 클라이언트의 관리 대상인지 확인합니다.
- 모드 확인: 규칙 모드와 글로벌 모드를 일시적으로 비교해 장애가 분할 라우팅에서 발생했는지 판단합니다.
- DNS 확인: 해석 경로와 연결 정책이 일치하는지 확인하고 기존 캐시를 삭제한 뒤 다시 테스트합니다.
- 충돌 확인: 다른 프록시, 가상 네트워크 어댑터 또는 네트워크 필터링 도구를 일시 중지해 라우팅이 중복으로 변경되지 않도록 합니다.
- 로그 보관: 오류 유형, 사용한 프로토콜, 연결 모드와 발생 단계를 기록한 뒤 지원 담당자에게 전달합니다.
오류 로그의 “시간 초과”는 일반적으로 정해진 대기 시간 안에 연결이 완료되지 않았다는 뜻이지만, 원인은 접속 지점에 도달할 수 없음, UDP 제한, DNS 해석 오류 또는 경로 혼잡일 수 있습니다. “인증 실패”는 키, 비밀번호, 식별 필드 또는 구독 상태 문제에 더 가깝고, “인증서 오류”는 서버 이름, 시스템 시간과 TLS 설정을 확인해야 합니다. 오류마다 대응 방법이 다르므로 노드를 반복해서 바꾸는 것만으로는 로그 분석을 대신할 수 없습니다.
문제를 해결할 때는 한 번에 하나의 변수만 변경하세요. 먼저 클라이언트와 모드를 고정한 뒤 노드를 바꾸고, 다음으로 노드를 고정한 채 규칙과 글로벌 모드를 비교합니다. 프로토콜, 노드, DNS와 클라이언트를 동시에 바꾸면 연결이 복구되더라도 실제 원인을 파악하기 어렵습니다.
용어를 이해한 뒤 초보자가 내릴 수 있는 선택 결론
구독은 설정을 클라이언트에 전달하고, 노드는 선택 가능한 연결 조합이며, 프로토콜은 통신 방식을 정하고, 회선은 하위 경로를 설명하며, 분할 라우팅은 어떤 요청이 프록시를 사용할지 결정합니다. 시스템 프록시와 TUN은 기기 트래픽을 클라이언트로 전달하는 역할을 합니다. DNS는 도메인 해석 단계에 있으며, 해석 경로가 분할 라우팅과 일치하지 않으면 올바르게 보이는 노드에서도 접속 오류가 발생할 수 있습니다.
일상적으로는 규칙 모드를 우선 선택해 로컬 서비스는 직결로 유지하고, 해외 접속은 규칙에 따라 적합한 노드로 보내는 것이 좋습니다. 특정 웹사이트에서 문제가 발생하면 잠시 글로벌 모드로 전환해 규칙을 확인하세요. 프로토콜은 클라이언트 호환성과 현재 네트워크를 우선하고, 회선은 실제 경로 성능을 기준으로 선택해야 합니다. 이름이 복잡하다고 더 적합한 것은 아닙니다. 안정적으로 가져오고, 올바르게 트래픽을 제어하며, 분할 라우팅이 명확하고 문제 해결이 쉬운 조합이 장기적으로 관리하기 좋은 설정입니다.