VPN이나 프록시 클라이언트를 처음 사용하면 구독, 노드, 회선 유형, 프로토콜, 분할 라우팅, 글로벌 모드와 규칙 모드가 서로 뒤섞여 보입니다. 하지만 각각의 계층은 다릅니다. 구독은 설정을 배포하고, 노드는 연결 가능한 서버 설정이며, 회선은 데이터가 노드에 도달하는 경로를 설명합니다. 프로토콜은 클라이언트와 서버의 통신 방식을 정하고, 분할 라우팅 모드는 어떤 요청을 프록시 경로로 보낼지 결정합니다.
이 용어들을 이해하기 위해 네트워크 원리를 처음부터 외울 필요는 없습니다. 한 번의 연결 과정을 순서대로 보면 훨씬 쉽습니다. 클라이언트가 구독을 읽어 노드 목록을 가져오고, 사용자가 노드를 선택하면 해당 프로토콜로 연결을 설정합니다. 이후 시스템 트래픽은 글로벌 모드나 규칙 모드에 따라 프록시 또는 직접 연결로 처리됩니다. 계층만 먼저 나누면 대부분의 설정 화면을 어렵지 않게 이해할 수 있습니다.
먼저 구독·노드·서버를 구분하세요
구독 링크는 업데이트 가능한 설정 접근 경로입니다
구독 링크는 보통 서비스 서버에서 생성됩니다. 클라이언트가 링크에 접속하면 노드 이름, 서버 주소, 포트, 프로토콜 매개변수와 필요한 인증 정보를 받아옵니다. 특정 노드가 아니라 원격 설정 목록에 가깝습니다. 서비스 서버에서 회선을 조정하면 클라이언트에서 ‘구독 업데이트’ 또는 ‘설정 새로 고침’을 실행해 항목별로 다시 입력하지 않아도 됩니다.
구독 링크는 인코딩된 텍스트를 반환할 수도 있고, Clash나 sing-box 등이 인식할 수 있는 설정 형식을 반환할 수도 있습니다. 브라우저에서 직접 열었을 때 긴 문자열이 표시되더라도 링크가 손상된 것은 아닙니다. 일반적으로 전체 링크를 복사한 뒤 클라이언트의 구독 가져오기 메뉴에 붙여 넣으면 됩니다.
노드는 클라이언트에서 선택할 수 있는 하나의 연결 설정입니다
노드에는 보통 대상 서버, 포트, 프로토콜, 인증 매개변수와 전송 설정이 포함됩니다. 클라이언트 목록의 ‘도쿄’, ‘싱가포르’, ‘미국’ 같은 이름은 대부분 식별을 위한 라벨입니다. 노드 이름이 같아도 실제 서버나 진입점, 네트워크 경로가 완전히 같다는 뜻은 아닙니다. 반대로 이름이 달라도 일부 인프라를 공유할 수 있습니다.
‘서버’는 물리적 또는 가상 컴퓨팅 자원에 가깝고, ‘노드’는 사용자가 연결할 수 있는 설정 항목에 가깝습니다. 하나의 서버가 여러 프로토콜이나 포트를 제공해 여러 노드 설정을 구성할 수 있습니다. 반대로 외부에 하나의 노드로 표시되어도 부하 분산에 따라 실제로는 서로 다른 백엔드에 연결될 수 있습니다. 따라서 노드를 고를 때는 이름보다 실제 연결 상태와 용도를 기준으로 판단하세요.
- ✅ 구독을 업데이트한 뒤 기존 노드가 교체되거나 이름이 바뀌었는지 먼저 확인하세요.
- ✅ 여러 구독을 가져올 때는 출처별로 알아보기 쉬운 그룹 이름을 지정하세요.
- ✅ 노드가 작동하지 않으면 먼저 구독을 새로 고친 뒤 클라이언트 시간과 네트워크 권한을 확인하세요.
- ❌ 구독 링크를 하나의 노드 주소로 오해해 수동으로 나누지 마세요.
- ❌ 지역명만 보고 회선 품질이나 구체적인 경로를 판단하지 마세요.
IEPL 전용 회선·중계·직접 연결이란
회선 유형은 로컬 네트워크가 원격 노드에 도달하는 방식을 설명합니다. Shadowsocks나 Trojan 같은 프로토콜과는 다른 개념입니다. 같은 프로토콜을 사용하는 두 노드도 서로 다른 회선을 이용할 수 있고, 같은 유형의 회선에도 여러 프로토콜을 실을 수 있습니다. ‘회선’과 ‘프로토콜’을 혼동하는 것은 초보자가 회선을 선택할 때 가장 흔한 실수입니다.
| 회선 유형 | 연결 경로 | 주요 특징 | 중점적으로 볼 항목 |
|---|---|---|---|
| 직접 연결 | 로컬 네트워크가 원격 노드에 직접 연결 | 구조가 단순하지만 로컬 통신사와 국제 출구의 영향을 크게 받음 | 경로 우회 여부, 저녁 시간대 변동, 패킷 손실 |
| 중계 | 가깝거나 안정적인 입구로 먼저 연결한 뒤 원격 출구로 전달 | 불리한 직접 연결 경로를 일부 개선할 수 있지만 입구와 중계 구간이 모두 결과에 영향을 줌 | 입구 위치, 전달 경로, 혼잡 시간대의 상태 |
| IEPL 전용 회선 | 통신사가 제공하는 국제 이더넷 전용 회선 자원으로 일부 경로를 전송 | 일반적으로 연결 안정성을 중시하지만 실제 품질은 서비스 설정과 로컬 접속 환경에 따라 달라짐 | 입구 접속, 출구 자원, 실제 애플리케이션 성능 |
직접 연결이 항상 더 빠른 것은 아닙니다
직접 연결은 중계 구간이 없지만 네트워크 경로가 가장 짧다는 보장은 없습니다. 통신사 간 또는 지역 간 연결, 국제 출구가 혼잡하면 데이터가 우회할 수 있습니다. 반대로 위치가 적절한 중계 입구를 사용하면 로컬 네트워크에서 입구까지를 비교적 안정적인 경로로 유지한 뒤 백엔드에서 국제 전송을 처리할 수 있습니다. 따라서 ‘거치는 서버가 적다’는 이유만으로 속도를 판단해서는 안 됩니다.
중계가 곧 노드 위치를 의미하는 것은 아닙니다
노드에 일본이라고 표시되어 있다면 일반적으로 출구가 일본에 있거나 일본 출구를 주요 용도로 사용한다는 뜻입니다. 하지만 중계 입구는 다른 지역에 있을 수 있습니다. 웹사이트에서 확인되는 출구 IP와 클라이언트가 처음 연결하는 입구의 위치가 항상 같은 것은 아닙니다. 문제를 점검할 때는 ‘입구 연결 실패’와 ‘출구 서비스 이상’을 구분해야 합니다.
IEPL은 회선 자원이지 암호화 프로토콜이 아닙니다
IEPL은 국제 이더넷 전용 회선 연결을 설명할 때 사용하는 표현입니다. 일부 네트워크 전송 경로의 문제를 다루지만 클라이언트 인증, 암호화 또는 트래픽 캡슐화 방식을 정의하지는 않습니다. 클라이언트는 여전히 특정 프로토콜을 사용해 서버에 연결해야 합니다. ‘IEPL 노드’라는 표현은 해당 노드의 일부 전송 구간에 관련 전용 회선 자원이 사용되었다는 의미이지, IEPL이라는 클라이언트 프로토콜이 새로 생겼다는 뜻은 아닙니다.
주요 프로토콜 이름의 의미
프로토콜은 클라이언트와 서버가 데이터를 인증하고 캡슐화하며 전송하는 방식을 결정합니다. 클라이언트가 노드에 사용된 프로토콜과 관련 전송 매개변수를 지원하지 않으면 서버 주소와 포트가 정확해도 연결할 수 없습니다. 아래 이름들은 구독 설정에 자주 등장하지만 각각 중점을 두는 설계가 다릅니다.
| 프로토콜 | 핵심 특징 | 설정 시 확인할 항목 | 흔한 오해 |
|---|---|---|---|
| Shadowsocks | 경량 암호화 프록시 프로토콜 | 암호화 방식, 비밀번호, 서버와 포트가 일치해야 함 | 모든 시스템 VPN 프로토콜과 완전히 같다고 생각함 |
| VMess | V2Ray 생태계에서 널리 사용되는 프록시 프로토콜 | 사용자 식별자, 전송 방식, TLS와 경로 매개변수 | 서버 주소만 입력하고 전송 계층 설정을 무시함 |
| Trojan | 일반적으로 TLS와 함께 사용하는 프록시 프로토콜 | 비밀번호, 도메인, 인증서 검증과 TLS 설정 | 인증서 검증을 끈 뒤에도 연결 검증이 완전하다고 생각함 |
| VLESS | 경량 프록시 프로토콜 프레임워크 | 사용자 식별자와 TLS, REALITY 등의 외부 보안 설정 | 프로토콜 자체가 모든 암호화 기능을 자동으로 제공한다고 생각함 |
| Hysteria2 | QUIC 기반 전송 방식으로, 복잡한 네트워크에서 처리량을 중시 | UDP 사용 가능 여부, 인증, TLS와 대역폭 매개변수 | UDP가 제한된 네트워크에서 같은 유형의 노드만 반복해 전환함 |
| TUIC | QUIC 기반 프록시 프로토콜 | UDP 환경, 사용자 인증 정보, 인증서와 혼잡 제어 설정 | 로컬 네트워크의 QUIC 또는 UDP 제한을 무시함 |
Shadowsocks 설정은 비교적 간결하고 호환되는 클라이언트가 많지만 암호화 방식은 서버와 일치해야 합니다. VMess와 VLESS는 WebSocket, gRPC, TCP, TLS 또는 REALITY 같은 전송·보안 계층과 함께 사용하는 경우가 많습니다. 구독 가져오기의 장점은 서로 연결된 매개변수를 하나의 완성된 설정으로 클라이언트에 전달해 수동 입력 누락을 줄인다는 데 있습니다.
Trojan은 TLS 및 도메인 인증서 검증과 함께 사용하는 경우가 많습니다. 기기 시간이 크게 틀렸거나 도메인 입력이 일치하지 않거나 인증서 검증에 실패하면 연결이 설정되지 않을 수 있습니다. 인증서 오류가 발생하면 인증서 검증을 바로 끄기보다 시스템 시간과 구독 설정을 확인해야 합니다.
Hysteria2와 TUIC은 모두 QUIC에 의존하며 주로 UDP에서 작동합니다. 지연 시간이 높거나 패킷 손실이 있는 일부 네트워크에서 전송 성능이 좋을 수 있지만, 로컬 네트워크가 해당 UDP 통신을 허용해야 합니다. 회사, 학교, 호텔 또는 공용 네트워크에서 UDP를 제한하면 이런 노드는 연결에 실패할 수 있습니다. 이때는 TCP 기반의 사용 가능한 노드로 바꿔 비교해 보세요.
구독 링크를 클라이언트로 가져오는 방법
클라이언트마다 버튼 이름은 다를 수 있지만 가져오기 과정은 대체로 같습니다. 먼저 신뢰할 수 있는 서비스 패널에서 구독 링크를 복사한 다음 클라이언트에서 원격 설정 또는 구독을 추가하고, 해석이 끝나면 노드를 선택하세요. 각 항목의 용도를 명확히 이해한 경우가 아니라면 구독 내용을 한 줄씩 수동 설정으로 다시 작성하지 마세요.
- 전체 링크 복사: 시작 부분, 매개변수 또는 마지막 문자가 누락되지 않았는지 확인하세요. 일부 메신저는 긴 링크를 잘라낼 수 있으므로 복사한 뒤 텍스트가 완전한지 먼저 점검하는 것이 좋습니다.
- 구독 관리 열기: 클라이언트에서 ‘구독’, ‘설정’, ‘원격 설정’ 또는 ‘URL에서 가져오기’와 같은 메뉴를 찾으세요.
- 붙여넣고 저장: 구독을 식별하기 쉬운 이름으로 지정한 뒤 업데이트를 실행하세요. 클라이언트에서 설정 형식을 선택하라고 하면 서비스 안내를 따르세요.
- 노드 선택: 프록시 그룹 또는 노드 목록에서 목표 지역을 선택하세요. 출구가 지정되지 않은 빈 설정에 그대로 두지 마세요.
- 실행 모드 선택: 일상적인 사용에는 보통 먼저 규칙 모드를 사용하고, 프록시 경로 전체를 테스트해야 할 때만 잠시 글로벌 모드로 전환하세요.
- 연결 확인: 네트워크 점검 페이지에 접속해 출구 IP와 DNS가 예상과 일치하는지 확인한 뒤 실제로 사용하려는 웹사이트나 애플리케이션을 테스트하세요.
구독을 업데이트하면 해당 구독으로 생성된 노드가 대체되는 경우가 많습니다. 구독 노드의 내부 매개변수를 직접 수정하면 다음 업데이트 때 원래 값으로 돌아갈 수 있습니다. 장기간 유지할 사용자 지정 규칙은 원격 노드를 직접 수정하기보다 클라이언트가 지원하는 덮어쓰기, 확장 설정 또는 로컬 규칙 파일에 저장하는 것이 적절합니다.
구독 링크
→ 클라이언트가 원격 설정 가져오기
→ 노드와 프록시 그룹 해석
→ 노드 선택
→ 프로토콜 연결 설정
→ 분할 라우팅 규칙으로 요청 경로 판단
→ 프록시 또는 직접 연결- ✅ 가져온 뒤 ‘추가 완료’ 알림만 보지 말고 노드 목록이 정상적으로 표시되는지 확인하세요.
- ✅ 클라이언트에 내장된 구독 업데이트 기능을 정기적으로 사용해 설정 변경 사항을 가져오세요.
- ✅ 클라이언트를 바꾸기 전에 새 클라이언트가 구독에 포함된 프로토콜과 전송 방식을 지원하는지 확인하세요.
- ❌ 출처가 불분명한 웹사이트에서 인증 정보가 포함된 구독 링크를 변환하지 마세요.
- ❌ 시스템 네트워크를 제어하는 클라이언트를 여러 개 동시에 실행한 상태에서 문제를 점검하지 마세요.
글로벌·규칙·직접 연결 모드 선택법
실행 모드는 트래픽이 클라이언트에 들어온 뒤 어떻게 처리될지 결정합니다. 노드 자체를 바꾸거나 직접 연결 회선을 중계 회선으로 바꾸지는 않습니다. 초보자는 ‘글로벌’이라는 말을 속도가 더 빨라진다는 뜻으로 오해하기 쉽지만, 실제로는 더 많은 요청을 현재 프록시 노드로 보낸다는 의미입니다.
글로벌 모드: 대부분의 트래픽을 프록시로 전송
글로벌 모드는 규칙 누락을 임시로 점검하거나 특정 웹사이트가 프록시 경로에서 접속되는지 확인할 때 유용합니다. 단점은 로컬 웹사이트, 로컬 네트워크 서비스와 프록시가 필요 없는 애플리케이션까지 우회 처리되어 지연이 늘어날 수 있다는 점입니다. 프린터, 라우터 관리 페이지 또는 로컬 개발 서비스에도 영향을 줄 수 있습니다.
규칙 모드: 도메인·IP·애플리케이션별 분류
규칙 모드는 규칙 집합에 따라 요청을 판단합니다. 일반적인 예로 로컬 네트워크 주소는 직접 연결하고, 국내에서 자주 사용하는 웹사이트는 직접 연결하며, 국제 회선이 필요한 도메인은 프록시로 보내고 광고나 악성 도메인은 규칙에 따라 차단합니다. 규칙은 도메인 접미사, 전체 도메인, IP 대역, 프로세스 이름 또는 규칙 모음을 기준으로 삼을 수 있으며 구체적인 기능은 클라이언트와 운영체제에 따라 다릅니다.
규칙 매칭에는 대개 순서가 있습니다. 더 구체적인 규칙을 포괄적인 규칙보다 앞에 배치해야 하며, 마지막까지 매칭되지 않은 트래픽은 기본 규칙이 처리합니다. 예를 들어 어떤 도메인이 앞쪽의 직접 연결 규칙에 이미 매칭되었다면 뒤쪽의 프록시 규칙은 적용되지 않습니다. ‘특정 웹사이트가 예상한 노드로 연결되지 않을 때’는 노드만 반복해서 전환하지 말고 연결 로그에서 매칭된 규칙을 확인하세요.
직접 연결 모드: 프록시 노드를 거치지 않음
직접 연결 모드는 프록시를 일시 중지하거나 로컬 네트워크 성능을 비교하거나 로컬 네트워크 기기에 접속할 때 사용합니다. 일부 클라이언트에서 ‘시스템 프록시 끄기’는 시스템 프록시를 따르는 애플리케이션의 제어만 중단할 뿐, 이미 활성화된 TUN 모드는 계속 트래픽을 처리할 수 있습니다. 따라서 연결을 일시 중지할 때는 시스템 프록시 스위치만 보지 말고 클라이언트 상태를 확인해야 합니다.
| 사용 상황 | 권장 모드 | 이유 |
|---|---|---|
| 일상적인 웹 이용과 업무를 함께 사용 | 규칙 모드 | 불필요한 우회를 줄이면서 대상 웹사이트의 프록시 접속을 유지 |
| 특정 웹사이트가 규칙에서 누락되었는지 점검 | 임시 글로벌 모드 | 규칙 문제와 노드 문제를 빠르게 구분할 수 있음 |
| 라우터 또는 로컬 네트워크 기기에 접속 | 직접 연결 또는 로컬 네트워크 우회 규칙 | 로컬 주소가 원격 노드로 전송되는 것을 방지 |
| 지정한 애플리케이션만 프록시 사용 | 애플리케이션별 분할 라우팅 | 프록시 범위를 제어하지만 클라이언트와 플랫폼의 지원이 필요 |
시스템 프록시·TUN·애플리케이션별 분할 라우팅의 차이
시스템 프록시는 운영체제가 애플리케이션에 제공하는 프록시 설정입니다. 브라우저와 일부 데스크톱 소프트웨어는 이를 따르지만, 일부 게임·명령줄 도구 또는 자체적으로 네트워크 연결을 설정하는 애플리케이션은 시스템 프록시를 무시할 수 있습니다. 그 결과 브라우저에는 적용되지만 다른 애플리케이션은 여전히 직접 연결되는 상황이 발생합니다.
TUN 모드는 가상 네트워크 인터페이스를 통해 더 넓은 범위의 IP 트래픽을 제어한 뒤 클라이언트가 프록시 또는 직접 연결 여부를 판단하게 합니다. 시스템 프록시 설정을 읽지 않는 애플리케이션에도 더 효과적이지만 추가 시스템 권한이 필요한 경우가 많고, 다른 네트워크 도구·방화벽·가상 머신 또는 기업 보안 소프트웨어와 라우팅 충돌이 발생하기도 쉽습니다.
애플리케이션별 분할 라우팅은 프로세스나 애플리케이션에 따라 트래픽 경로를 결정합니다. 모바일 플랫폼에서는 ‘선택한 앱만 프록시 사용’ 또는 ‘선택한 앱 우회’가 흔하고, 데스크톱 클라이언트에서는 프로세스 규칙을 제공하기도 합니다. 애플리케이션 업데이트 후 실행 파일 경로가 바뀌면 기존 규칙이 더 이상 매칭되지 않을 수 있으므로 실제 프로세스 이름을 확인해야 합니다.
- ✅ 브라우저에는 적용되지만 게임에는 적용되지 않을 때 게임이 시스템 프록시를 무시하는지 확인하세요.
- ✅ TUN을 켠 뒤 로컬 네트워크에 접속할 수 없다면 로컬 네트워크 우회와 라우팅 규칙을 확인하세요.
- ✅ 애플리케이션별 분할 라우팅이 작동하지 않으면 프로세스 이름과 클라이언트 실행 권한을 확인하세요.
- ❌ 시스템 프록시, TUN 및 다른 네트워크 도구가 같은 트래픽을 중복으로 제어하는 상태에서 감으로 장애 원인을 판단하지 마세요.
DNS 누출과 분할 라우팅이 서로 연결되는 이유
도메인에 접속하기 전에 기기는 보통 DNS를 통해 도메인 이름을 IP 주소로 변환합니다. 웹 트래픽은 프록시를 통과하지만 DNS 요청은 예상과 다른 로컬 리졸버로 전송되면 접속 도메인의 조회 정보가 노출될 수 있고, 프록시 출구 지역과 맞지 않는 주소를 받을 수도 있습니다. 이를 일반적으로 DNS 누출 또는 DNS 경로 불일치라고 합니다.
도메인 기반 규칙 분할 라우팅을 사용하려면 클라이언트가 적절한 단계에서 도메인 정보를 가져와야 합니다. 애플리케이션이 먼저 도메인을 해석한 뒤 IP만 클라이언트에 전달하면 순수 도메인 규칙이 매칭되지 않을 수 있습니다. DNS가 지역에 따라 달라지는 주소를 반환하면 콘텐츠 전송 네트워크가 적절하지 않은 입구를 선택할 수도 있습니다. 그래서 최신 클라이언트는 DNS, 규칙 매칭과 프록시 연결을 하나의 설정 체계에서 처리하는 경우가 많습니다.
일반적인 점검 순서
- 클라이언트의 DNS 모듈이 활성화되어 있는지 확인하고 현재 사용 중인 해석 방식을 확인하세요.
- 브라우저 자체의 암호화 DNS 설정이 클라이언트 설정을 우회하는지 확인하세요.
- 대상 도메인이 직접 연결, 프록시 또는 기본 규칙 중 어디에 매칭되었는지 확인하세요.
- 운영체제와 브라우저의 DNS 캐시를 삭제한 뒤 다시 테스트하세요.
- 네트워크 점검 페이지에서 출구 IP와 DNS 리졸버가 현재 모드의 예상과 일치하는지 비교하세요.
DNS 점검 결과는 리졸버 이름만 보고 판단해서는 안 됩니다. 일부 공용 리졸버는 글로벌 라우팅을 사용하므로 표시된 지역이 실제 네트워크 경로와 다를 수 있습니다. 더 중요한 것은 요청이 예상대로 클라이언트를 통해 처리되는지, 로컬 통신사 리졸버가 나타나는지, 모드를 바꿨을 때 결과가 합리적으로 달라지는지 확인하는 것입니다.
플랫폼별 클라이언트 차이
같은 구독이라도 플랫폼에 따라 표시 방식과 사용할 수 있는 기능이 달라질 수 있습니다. 이는 대개 구독 내용이 바뀌어서가 아니라 운영체제 권한, 클라이언트 핵심과 네트워크 제어 방식이 다르기 때문입니다.
Windows
Windows 클라이언트는 보통 시스템 프록시와 TUN을 함께 제공합니다. 시스템 프록시는 브라우저와 시스템 설정을 따르는 소프트웨어에 적합하지만, 게임·스토어 앱 또는 일부 명령줄 프로그램에는 TUN이 필요할 수 있습니다. TUN을 켜면 클라이언트가 가상 네트워크 어댑터를 만들고 라우팅을 설정하기 위해 관리자 권한을 요청할 수 있습니다.
macOS
macOS의 시스템 프록시도 모든 애플리케이션을 제어하지는 못합니다. 네트워크 확장 또는 가상 인터페이스를 사용할 때는 시스템에서 사용자 승인을 요청합니다. 클라이언트 업데이트 후 연결에 이상이 생기면 네트워크 확장 권한이 여전히 유효한지, 시스템에 다른 VPN 설정이 남아 있는지 확인하세요.
Android
Android 클라이언트는 보통 시스템 VPN 인터페이스를 통해 트래픽을 제어하며 애플리케이션별 분할 라우팅을 제공할 수 있습니다. 시스템은 일반적으로 한 번에 하나의 활성 VPN 채널만 허용하므로 다른 방화벽·광고 차단 또는 기업 네트워크 애플리케이션이 프록시 클라이언트와 서로 연결을 대체할 수 있습니다.
iOS 및 iPadOS
iOS와 iPadOS 클라이언트는 시스템에서 제공하는 네트워크 확장 기능에 의존합니다. 클라이언트마다 지원하는 프로토콜 핵심이 완전히 같지는 않습니다. 가져오기는 성공했지만 노드가 시작되지 않는다면 먼저 프로토콜과 전송 방식이 지원되는지 확인하세요. 시스템의 애플리케이션별 제어 기능도 앱의 capabilities와 기기 관리 정책의 영향을 받습니다.
연결 실패 시 계층별 점검
효율적인 점검 방법은 여러 노드를 연속해서 눌러 보는 것이 아니라 장애가 어느 계층에서 발생했는지 판단하는 것입니다. 먼저 로컬 네트워크를 확인하고, 다음으로 구독과 노드를 확인한 뒤 프로토콜 연결을 점검하고 마지막으로 규칙과 DNS를 확인하세요. 한 번에 하나의 변수만 바꿔야 어떤 조정이 영향을 주었는지 알 수 있습니다.
- ✅ 로컬 네트워크 계층: 프록시를 끈 뒤 일반 웹사이트에 정상적으로 접속되는지 확인하세요.
- ✅ 구독 계층: 구독을 업데이트하고 로그인 페이지나 오류 텍스트가 아닌 노드가 반환되는지 확인하세요.
- ✅ 노드 계층: 같은 구독에 포함된 다른 사용 가능한 노드를 선택해 비교하세요.
- ✅ 프로토콜 계층: 로그에서 시간 초과, 인증서, 인증, UDP 또는 지원되지 않는 매개변수 관련 메시지를 확인하세요.
- ✅ 제어 계층: 시스템 프록시 또는 TUN이 예상대로 활성화되어 있고 다른 도구와 충돌하지 않는지 확인하세요.
- ✅ 규칙 계층: 대상 연결에 매칭된 규칙과 프록시 그룹을 확인하세요.
- ✅ DNS 계층: 해석 경로, 캐시와 브라우저의 독립 설정을 확인하세요.
- ❌ 노드, 프로토콜, DNS와 실행 모드를 동시에 바꾸지 마세요. 원인을 찾을 수 없게 됩니다.
로그의 ‘시간 초과’는 정해진 시간 안에 연결이 완료되지 않았다는 뜻일 뿐이며 서버, 회선 또는 로컬 네트워크 중 어느 쪽에 문제가 있는지는 단독으로 알려주지 않습니다. ‘인증 실패’는 인증 정보나 시스템 시간 문제일 가능성이 높고, ‘인증서 이름 불일치’는 보통 도메인, TLS 설정과 시스템 시간을 확인해야 합니다. ‘지원되지 않는 프로토콜 또는 전송’은 클라이언트 핵심 버전을 확인해야 합니다.
이 계층 구조를 익히면 설정 화면의 용어를 하나로 연결할 수 있습니다. 구독은 설정을 제공하고, 노드는 연결 대상을 제공하며, 회선은 대상까지의 경로에 영향을 줍니다. 프로토콜은 통신 방식을 정하고, 시스템 프록시 또는 TUN은 트래픽을 제어하며, 규칙 모드는 요청의 경로를 결정하고, DNS는 도메인 해석과 분할 라우팅 판단에 관여합니다. 선택할 때 가장 긴 기능 목록을 좇을 필요는 없습니다. 현재 플랫폼과 네트워크 환경에서 안정적으로 작동하는지가 더 현실적인 기준입니다.