VPN 용어 총정리: 구독, 노드, 프로토콜과 분할 라우팅

전체 연결 과정부터 보기: 각 용어는 어느 단계에 해당할까

VPN 용어를 이해하는 가장 효과적인 방법은 정의를 하나씩 외우는 것이 아니라 실제 연결 과정을 따라가 보는 것입니다. 사용자는 먼저 서비스 관리 콘솔에서 구독 링크를 받아 클라이언트로 가져옵니다. 클라이언트는 구독에 포함된 노드 설정을 읽고 프로토콜, 전송 방식, 인증 정보를 바탕으로 연결을 수립합니다. 연결이 완료되면 분할 라우팅 규칙이 어떤 요청을 노드로 보낼지 결정하고, DNS 설정이 도메인을 주소로 변환하며, 출구 서버가 기기를 대신해 대상 웹사이트에 접속합니다.

이 과정에서 ‘구독’은 설정을 배포하고, ‘노드’는 연결 가능한 진입점 또는 출구를 설명하며, ‘프로토콜’은 클라이언트와 서버의 통신 방식을 정하고, ‘회선’은 노드 뒤의 네트워크 경로를 나타내며, ‘분할 라우팅’은 요청이 프록시를 거칠지 결정합니다. 서로 연결되어 있지만 같은 개념은 아닙니다. 구독이 정상적으로 갱신된다고 해서 모든 노드가 현재 네트워크에 적합한 것은 아니며, 특정 프로토콜로 핸드셰이크에 성공했다고 해서 대상 웹사이트가 반드시 해당 회선을 이용하는 것도 아닙니다.

구독 링크, 노드와 설정 파일의 차이

구독 링크는 설정을 가져오는 경로이지 노드 자체가 아닙니다

구독 링크는 보통 서비스 관리 콘솔에서 생성됩니다. 클라이언트가 이 주소에 접속하면 인코딩되었거나 구조화된 설정 데이터를 받아오며, 여기에는 노드 이름, 서버 주소, 인증 정보, 프로토콜 유형, 전송 매개변수 등이 포함될 수 있습니다. 클라이언트의 ‘구독 업데이트’는 이 데이터를 다시 요청해 로컬 목록을 갱신하는 작업입니다.

구독 링크에는 계정이나 서비스 권한을 식별할 수 있는 토큰이 포함되는 경우가 많으므로 비밀번호처럼 안전하게 보관해야 합니다. 전체 링크를 공개 웹페이지, 스크린샷, 포럼 또는 코드 저장소에 게시하지 마세요. 고객지원에 문제를 설명할 때는 클라이언트 오류와 노드 이름을 전달할 수 있지만, 링크에 포함된 식별 매개변수는 가려야 합니다.

구독 업데이트 실패와 노드 연결 실패는 따로 판단해야 합니다. 전자는 링크 만료, 구독 주소에 대한 네트워크 접속 불가, 클라이언트 형식 비호환과 관련될 수 있고, 후자는 노드 점검, 로컬 네트워크 제한, 프로토콜 매개변수 불일치 또는 시스템 시간 오류 때문일 수 있습니다. 기존 노드가 계속 연결되더라도 구독 갱신은 이미 막혔을 수 있으며, 반대로 구독 업데이트에 성공했다고 해서 모든 회선이 현재 환경에 적합한 것은 아닙니다.

노드는 실행 가능한 연결 매개변수의 묶음입니다

클라이언트 목록에 표시되는 ‘일본’, ‘싱가포르’ 또는 기타 지역명은 식별을 돕기 위한 라벨일 뿐입니다. 실제 노드 설정에는 서버 주소, 연결 포트, 사용자 인증 정보, 프로토콜, 전송 계층과 보안 계층 매개변수도 포함됩니다. 노드 이름이 같아도 서로 다른 진입점, 중계 구간 또는 프로토콜에 연결될 수 있습니다.

노드 지역은 일반적으로 출구 주소가 위치한 지역을 의미하지만, 서비스에 따라 진입점, 용도 또는 회선 유형을 기준으로 이름을 정할 수도 있습니다. 출구 위치를 확인하려면 연결 후 4kVPN의 내 IP 페이지에서 확인하고, 클라이언트에 표시된 이름만으로 추정하지 마세요. 브라우저 위치 정보, 계정 지역 및 웹사이트 캐시도 페이지 표시 내용에 영향을 줄 수 있으며, 이는 출구 IP와는 별개의 정보입니다.

수동 설정과 구독 가져오기

수동 설정은 서버, 인증, 프로토콜과 전송 매개변수를 하나씩 입력하는 방식으로, 각 필드의 의미를 명확히 파악할 수 있어 개별 테스트에 적합합니다. 구독 가져오기는 일상적인 사용에 더 편리합니다. 서버에서 노드를 조정한 뒤 클라이언트가 구독을 업데이트해 변경 사항을 받을 수 있기 때문입니다. 두 방식의 연결 원리는 본질적으로 같고, 설정이 클라이언트에 들어오는 방식이 다를 뿐입니다.

1. 서비스 관리 콘솔에서 구독 링크를 복사하고, 신뢰할 수 없는 중계 웹페이지를 통한 변환은 피하세요.
2. 호환 클라이언트에서 ‘구독’, ‘설정 소스’ 또는 이와 유사한 메뉴를 찾습니다.
3. 링크를 붙여넣고 업데이트를 실행한 뒤 목록에 노드와 프로토콜 정보가 표시되는지 확인합니다.
4. 노드를 선택해 연결한 다음 출구 IP와 DNS 상태를 확인합니다.
5. 서버 설정이 변경되면 먼저 구독을 업데이트하고, 이미 캐시된 오래된 매개변수에 장기간 의존하지 마세요.

직접 연결, 중계와 IEPL 전용 회선이 의미하는 것

프로토콜은 ‘데이터를 어떻게 캡슐화하고 전송할지’를 해결하고, 회선은 ‘데이터가 실제로 어디를 거칠지’를 결정합니다. 같은 프로토콜이 서로 다른 회선에서 작동할 수 있고, 같은 회선에 여러 프로토콜이 사용될 수도 있습니다. 따라서 노드를 비교할 때는 프로토콜 이름만 보지 말고 로컬 네트워크, 접속 대상과 회선 경로를 함께 고려해야 합니다.

직접 연결 회선

직접 연결은 클라이언트가 대상 지역의 서버에 바로 연결하는 방식으로, 서비스 제공자가 별도로 구성한 접속 중계 구간이 없습니다. 구조가 단순하고 경로는 주로 로컬 통신사와 인터넷 라우팅에 의해 결정됩니다. 실제 사용 환경은 망간 연동, 국제 출구 혼잡과 우회 라우팅의 영향을 받습니다. 같은 직접 연결 노드라도 지역과 접속 네트워크에 따라 성능이 크게 달라질 수 있습니다.

중계 회선

중계 회선은 먼저 가깝거나 접속하기 쉬운 진입점에 연결한 다음, 진입점이 최종 출구로 전달합니다. 중계의 목적은 품질이 좋지 않은 직접 연결 경로를 피하거나 진입점과 출구를 통합 관리하는 데 있습니다. 전달 단계가 하나 늘어나지만 반드시 더 느린 것은 아닙니다. 진입점과 출구 사이의 경로가 더 안정적이라면 심하게 우회하는 직접 연결보다 전체 사용감이 나을 수 있습니다.

중계를 선택할 때는 로컬 네트워크에서 진입점까지, 진입점에서 출구까지의 두 구간을 나누어 살펴봐야 합니다. 진입점에는 연결되지만 출구에 문제가 있으면 클라이언트에는 연결 완료로 표시되면서도 웹 요청이 끝나지 않을 수 있습니다. 이런 문제는 로그를 통해 핸드셰이크 후 데이터가 없는 것인지, 대상 사이트가 출구 요청을 거부한 것인지 확인해야 합니다.

IEPL 전용 회선

IEPL은 일반적으로 국제 이더넷 전용 회선 계열의 연결을 의미하며, 통신사 전용 전송망을 통해 서로 다른 지역의 네트워크 접속 지점을 연결하는 데 사용됩니다. 사용자용 노드 이름에서 ‘IEPL 전용 회선’은 중간 백본 구간이 일반 공용 인터넷 직접 연결과 다르다는 점을 강조하는 경우가 많습니다. 다만 사용자 기기에서 접속 지점까지, 출구에서 대상 웹사이트까지는 여전히 로컬 네트워크나 공용 인터넷을 거칠 수 있습니다.

따라서 IEPL을 기기에서 모든 웹사이트까지 이어지는 전체 물리적 전용 회선으로 이해해서는 안 되며, 라벨만으로 고정된 지연 시간이나 대역폭을 추정할 수도 없습니다. 더 현실적인 판단 방법은 자신의 접속 네트워크에서 연결 수립이 안정적인지, 지속 전송이 원활한지, 대상 플랫폼에 정상적으로 접속되는지를 비교하는 것입니다. 4kVPN의 글로벌 노드 페이지에서 지역과 회선 유형을 확인할 수 있으며, 동적 상태는 실제 연결 시 클라이언트 결과를 기준으로 판단해야 합니다.

Shadowsocks, VMess, Trojan, VLESS, Hysteria2 및 TUIC

프로토콜은 클라이언트와 서버가 인증하고 데이터를 캡슐화해 전송하는 방식을 정하지만, 현대적인 프록시 연결에는 전송 계층과 보안 계층이 추가되는 경우가 많습니다. 프로토콜 이름을 확인했다면 TCP, WebSocket, gRPC 또는 QUIC 중 어떤 전송 위에서 작동하는지, TLS를 사용하는지, 서버 이름과 인증서 검증 등의 매개변수가 올바른지도 확인해야 합니다.

Shadowsocks

Shadowsocks는 암호화 프록시 프로토콜이며, 핵심 설정에는 일반적으로 서버, 포트, 비밀번호와 암호화 방식이 포함됩니다. 구조가 비교적 단순하고 클라이언트 지원 범위가 넓어 설정 복잡도를 낮추고 싶은 환경에 적합합니다. 데이터 복호화가 이루어지려면 클라이언트와 서버가 호환되는 암호화 방식과 매개변수를 사용해야 합니다. 자체적으로 전통적인 의미의 전체 기기 VPN은 아니며, 모든 애플리케이션을 처리할지는 클라이언트가 시스템 프록시, TUN 모드 또는 다른 전달 방식을 사용하는지에 따라 달라집니다.

VMess

VMess는 V2Ray 생태계에서 흔히 사용되며 인증 메커니즘을 포함하고 여러 전송 방식과 함께 사용할 수 있습니다. 일부 구현은 시스템 시간 오차에 민감하므로 인증 실패가 발생하면 기기의 시간과 시간대가 시스템에 의해 자동으로 보정되는지 확인해야 합니다. VMess는 연결 설정의 일부일 뿐이며 WebSocket 경로, 호스트 이름, TLS와 전송 매개변수도 서버와 일치해야 합니다.

VLESS

VLESS는 인증과 데이터 구조를 간소화한 방식으로, 자체적으로 완전한 전송 암호화를 제공하지 않으며 보통 TLS, REALITY 또는 보호된 하위 전송과 함께 사용합니다. VLESS 설정의 보안성을 판단할 때는 프로토콜 이름만 보지 말고 보안 계층이 활성화되었는지, 인증서 또는 공개 키 매개변수가 일치하는지, 클라이언트가 올바른 서버 신원 확인을 수행하는지 살펴봐야 합니다.

Trojan

Trojan은 일반적으로 TLS 위에서 작동하며 비밀번호로 인증하고, 연결 형태가 일반적인 TLS 트래픽과 유사합니다. 설정 시 서버 이름, 인증서 검증과 비밀번호가 자주 사용되는 필드입니다. 인증서 검증을 끄면 설정 오류를 일시적으로 피할 수 있지만 서버 신원 확인이 약해지므로 장기적인 문제 해결 방법으로 적합하지 않습니다. 도메인, 인증서와 기기 시간을 점검하는 편이 더 합리적입니다.

Hysteria2

Hysteria2는 UDP와 QUIC 개념을 바탕으로 설계되었으며, 불안정하거나 패킷 손실이 많은 경로를 위한 혼잡 제어 메커니즘을 포함합니다. 적합한 네트워크에서는 지속 전송 성능이 좋을 수 있지만, 로컬 네트워크가 UDP 통신을 허용하고 라우터, 방화벽과 통신사 경로에 심각한 제한이 없어야 합니다. UDP가 차단되었거나 품질이 매우 낮다면 관련 없는 분할 라우팅 규칙을 반복해서 수정하기보다 사용 가능한 다른 프로토콜을 선택해야 합니다.

TUIC

TUIC 역시 QUIC와 UDP를 기반으로 하며 다중화와 연결 관리를 강조합니다. Hysteria2와 매개변수를 서로 바꿔 사용할 수 있는 동일한 프로토콜이 아니므로 클라이언트와 서버가 각 구현을 별도로 지원해야 합니다. ‘프로토콜을 지원하지 않음’ 오류가 나타나면 TUIC 노드를 일반 TLS 노드로 보고 수동 입력하기보다 클라이언트 버전과 핵심 기능부터 확인해야 합니다.

분할 라우팅, 글로벌 모드와 규칙 모드의 작동 방식

분할 라우팅은 클라이언트가 각 네트워크 요청에 대해 내리는 경로 결정입니다. 일반적인 결과에는 프록시, 직접 연결과 차단이 있습니다. 판단 기준은 도메인, 대상 IP, 애플리케이션 프로세스, 포트, 지역 데이터베이스 또는 사용자 지정 규칙일 수 있으며, 구체적인 기능은 클라이언트와 실행 플랫폼에 따라 달라집니다.

글로벌 모드

글로벌 모드는 일반적으로 클라이언트가 처리하는 트래픽을 기본적으로 모두 현재 노드로 보내는 방식입니다. 특정 요청이 규칙에 매칭되지 않아 직접 연결된 것인지 임시로 확인하거나, 짧은 시간 동안 출구를 통일해야 할 때 적합합니다. 하지만 글로벌 모드라고 해서 기기의 모든 데이터 패킷이 반드시 노드를 거치는 것은 아닙니다. 시스템 프록시가 처리하지 않는 애플리케이션, 로컬 네트워크 통신, 시스템 서비스 또는 클라이언트가 지원하지 않는 프로토콜은 여전히 기존 경로를 사용할 수 있습니다. TUN 모드를 켜면 처리 범위를 넓힐 수 있지만, 클라이언트 안내와 라우팅 테이블을 기준으로 판단해야 합니다.

규칙 모드

규칙 모드는 요청을 순서대로 매칭합니다. 예를 들어 로컬 네트워크 주소는 직접 연결하고, 지정한 국제 웹사이트는 프록시로 보내며, 광고 도메인은 차단하고, 나머지 요청에는 기본 정책을 적용할 수 있습니다. 규칙에는 보통 우선순위가 있어 앞에서 이미 매칭된 요청은 뒤의 규칙을 계속 적용하지 않습니다. 따라서 사용자 지정 규칙이 작동하지 않을 때는 규칙 내용뿐 아니라 더 앞선 규칙에 의해 덮어쓰였는지도 확인해야 합니다.

도메인 규칙과 IP 규칙도 서로 다릅니다. 도메인 규칙을 적용하려면 클라이언트가 원래 도메인을 확인할 수 있어야 합니다. 애플리케이션이 이미 자체적으로 DNS를 조회했다면 클라이언트에는 대상 IP만 보일 수 있습니다. 반대로 하나의 도메인이 동적으로 변하는 주소로 해석될 수 있어 고정 IP 규칙만으로는 쉽게 무효화됩니다. 정교한 규칙 세트는 일반적으로 도메인, IP 데이터와 DNS 처리를 함께 사용합니다.

직접 연결과 로컬 네트워크 우회

직접 연결은 요청이 원격 노드를 거치지 않고 로컬 네트워크를 통해 정상적으로 접속하는 방식입니다. 프린터, 라우터 관리 페이지, 로컬 네트워크 저장 장치와 같은 자원은 보통 직접 연결이 필요합니다. 글로벌 모드 때문에 이러한 자원에 접근할 수 없다면 ‘로컬 네트워크 우회’를 활성화하거나 로컬 주소 규칙을 추가할 수 있습니다. 직접 연결 규칙은 로컬 네트워크의 기존 출구를 노출한다는 점에 유의해야 합니다. 이는 분할 라우팅의 설계 결과이며 연결 장애와는 다릅니다.

시스템 프록시와 TUN 모드

시스템 프록시는 주로 운영체제의 프록시 설정을 따르는 애플리케이션에 영향을 줍니다. 브라우저는 대체로 지원이 좋지만 일부 게임, 명령줄 도구와 자체 네트워크 스택을 사용하는 소프트웨어는 이를 무시할 수 있습니다. TUN 모드는 가상 네트워크 인터페이스를 통해 더 넓은 IP 트래픽을 처리하며 보통 적용 범위가 더 넓지만, 방화벽, 기업용 네트워크 소프트웨어 또는 다른 VPN 설정과 충돌할 가능성도 커집니다.

브라우저는 접속되지만 특정 애플리케이션이 접속되지 않는다면 먼저 해당 애플리케이션이 시스템 프록시를 따르는지 확인하세요. 모든 애플리케이션이 네트워크에 연결되지 않는다면 TUN 라우팅, DNS와 시스템 방화벽을 점검해야 합니다. ‘시스템 프록시가 애플리케이션을 처리하지 않음’을 노드 장애로 오해하지 마세요.

DNS, 원격 조회와 DNS 누출

DNS의 역할은 도메인을 연결 가능한 IP 주소로 변환하는 것입니다. 브라우저가 웹사이트에 접속할 때는 보통 먼저 도메인을 조회한 다음 네트워크 연결을 수립합니다. 프록시가 연결되었다고 해서 DNS 요청까지 자동으로 같은 경로를 통과하는 것은 아닙니다. 이는 클라이언트의 DNS 모드, 시스템 설정과 애플리케이션 자체 동작에 따라 달라집니다.

DNS 누출이란

관련 요청을 모두 프록시로 보내야 하는 환경에서 도메인 조회가 로컬 네트워크가 제공하는 DNS 서버로 계속 전송되면 일반적으로 DNS 누출이라고 합니다. 이 경우 로컬 DNS 제공자가 조회한 도메인을 볼 수 있거나, 로컬과 원격의 조회 결과가 달라 웹사이트 접속에 문제가 생길 수 있습니다.

확인할 때 출구 IP만 보지 마세요. DNS 확인 페이지에 표시되는 DNS 서버가 현재 설정과 일치하는지 함께 확인하고, 브라우저에서 별도의 보안 DNS가 활성화되어 있는지도 살펴봐야 합니다. 브라우저 내장 암호화 DNS는 조회 전송을 보호할 수 있지만, 로컬 직접 연결 출구를 선택한다면 조회가 프록시 노드를 통해 전달되었다는 뜻은 아닙니다.

로컬 조회와 원격 조회

로컬 조회는 기기나 로컬 네트워크가 먼저 대상 IP를 가져온 뒤 분할 라우팅 엔진이 연결 방식을 결정합니다. 응답은 빠르지만 도메인 정보가 로컬 경로에 남을 수 있습니다. 원격 조회는 프록시 측 또는 지정된 원격 DNS 서버에 조회를 맡기는 방식으로, 도메인 판단과 출구 지역을 일치시키기 쉽습니다. 클라이언트에 따라 프록시 DNS, 원격 DNS, Fake IP 또는 강화 모드 등으로 표시될 수 있으며 구현은 완전히 같지 않습니다.

Fake IP 모드는 먼저 클라이언트가 관리하는 매핑 주소를 애플리케이션에 반환한 다음 내부에서 실제 도메인과 연결하고 분할 라우팅을 수행합니다. 도메인 정보를 유지하는 데 도움이 되지만 일부 로컬 네트워크 서비스, 기기 검색 또는 특수한 DNS 결과에 의존하는 애플리케이션과 호환되지 않을 수 있습니다. 문제가 발생하면 전체 DNS 관리를 끄기보다 관련 도메인을 제외 목록에 추가해 보세요.

1. 연결 전에 현재 출구와 DNS 조회 상태를 기록합니다.
2. 노드에 연결한 뒤 출구 IP를 다시 확인해 트래픽이 실제로 전환되었는지 확인합니다.
3. DNS 조회 서버가 클라이언트 설정과 일치하는지 확인합니다.
4. 브라우저와 다른 애플리케이션을 각각 테스트해 애플리케이션 자체 DNS가 있는지 판단합니다.
5. 규칙 모드와 글로벌 모드를 전환해 비교하면서 DNS 문제인지 분할 라우팅 규칙 문제인지 확인합니다.

Windows, macOS, iOS, Android와 Linux 클라이언트의 차이

같은 구독이라도 플랫폼에 따라 다른 옵션으로 표시될 수 있습니다. 이는 운영체제 네트워크 인터페이스와 클라이언트 핵심 기능의 차이 때문이며 구독 내용이 바뀐 것은 아닙니다. 가져오기 전에 클라이언트가 구독에 포함된 프로토콜, 전송 방식과 보안 매개변수를 지원하는지 확인해야 합니다.

Windows

Windows 클라이언트는 시스템 프록시와 TUN 모드를 함께 제공하는 경우가 많습니다. 시스템 프록시는 브라우저 트래픽을 빠르게 전환하기 편하고, TUN은 프록시 설정을 따르지 않는 애플리케이션까지 처리하는 데 적합합니다. TUN을 활성화하려면 시스템 권한이 필요할 수 있으며, 다른 가상 네트워크 어댑터, 기업용 보안 소프트웨어 또는 기존 VPN 연결과 충돌하는지 확인해야 합니다.

macOS

macOS도 시스템 프록시 또는 네트워크 확장을 통해 트래픽을 처리할 수 있습니다. 관련 확장을 처음 활성화하면 시스템에서 권한 확인을 요청합니다. 클라이언트에는 연결됨으로 표시되지만 일부 애플리케이션이 계속 직접 연결된다면 현재 시스템 프록시를 사용하는지 가상 네트워크 인터페이스를 사용하는지 확인하고, 애플리케이션 자체 프록시 또는 DNS 설정이 있는지도 살펴보세요.

iOS와 Android

모바일 플랫폼의 프록시 클라이언트는 보통 시스템 VPN 인터페이스를 이용해 트래픽을 처리합니다. 상태 표시줄에 VPN 아이콘이 나타난다는 것은 시스템 네트워크 확장이 실행 중이라는 뜻일 뿐이며, 노드 출구와 DNS가 모두 예상대로 작동한다는 것을 단독으로 증명하지는 않습니다. 모바일 운영체제는 일반적으로 하나의 주요 VPN 설정만 활성 상태로 허용하므로 광고 차단, 기업용 접속과 프록시 클라이언트가 인터페이스를 서로 점유할 수 있습니다.

Android 기기에는 항상 켜진 VPN, 앱별 분할 라우팅과 같은 시스템 기능이 추가로 제공될 수 있습니다. 제조사별 절전 정책이 클라이언트의 백그라운드 실행을 제한할 수도 있습니다. iOS의 분할 라우팅 기능은 클라이언트 네트워크 확장의 구현 방식에 더 크게 좌우됩니다. 모바일 기기에서 대기 후 연결이 끊긴다면 먼저 시스템 권한과 백그라운드 정책을 확인한 뒤 노드 변경을 고려하세요.

Linux

Linux 환경에서는 그래픽 클라이언트뿐 아니라 명령줄 핵심 기능, 시스템 서비스와 라우팅 규칙을 통해 실행하는 방식도 사용됩니다. 시스템 프록시 환경 변수는 이를 직접 읽는 프로그램에만 적용되며 투명 전달이나 TUN을 대신할 수 없습니다. 문제를 해결할 때는 프로세스 실행 여부, 리스닝 상태, 라우팅 테이블 갱신 여부와 시스템 네트워크 관리 서비스가 DNS 설정을 덮어썼는지 확인해야 합니다.

연결 이상은 계층별로 확인하고 모든 옵션을 동시에 바꾸지 마세요

용어가 진정으로 유용한 이유는 문제를 검증 가능한 단계로 나누도록 도와주기 때문입니다. 프로토콜, DNS, 노드, 분할 라우팅과 시스템 프록시를 한 번에 수정하면 문제가 일시적으로 사라질 수 있지만 원인을 알 수 없습니다. 다음 순서로 확인하면 재현과 원인 파악이 더 쉽습니다.

구독을 업데이트할 수 없음

• 복사한 구독 링크가 완전한지, 공백이나 잘린 문자가 섞이지 않았는지 확인합니다.
• 서비스 상태와 구독 권한이 여전히 유효한지 확인합니다.
• 클라이언트가 해당 구독 형식을 지원하는지 확인하고 업데이트 로그의 네트워크 오류를 살펴봅니다.
• 인증 정보가 포함된 링크를 출처가 불분명한 온라인 변환 도구로 처리하지 마세요.

노드 연결을 수립할 수 없음

• 먼저 같은 프로토콜의 다른 노드로 바꿔 단일 노드 문제인지 프로토콜 전체의 문제인지 확인합니다.
• 시스템 시간을 보정합니다. 특히 VMess, TLS 또는 인증서 검증을 사용할 때 중요합니다.
• Hysteria2 또는 TUIC을 사용할 때 현재 네트워크가 UDP를 허용하는지 확인합니다.
• 서버 이름, 전송 경로, 인증과 인증서 관련 매개변수를 확인합니다.

연결됨으로 표시되지만 웹페이지가 열리지 않음

• 출구 IP가 바뀌었는지 확인해 핸드셰이크 성공과 실제 전달 성공을 구분합니다.
• 글로벌 모드로 전환해 비교하면서 대상 도메인이 규칙에서 빠졌는지 확인합니다.
• DNS가 응답을 반환하는지, 응답이 잘못된 경로로 라우팅되지 않는지 확인합니다.
• 브라우저에 만료된 프록시 설정이나 별도의 네트워크 확장이 남아 있지 않은지 확인합니다.

브라우저는 작동하지만 다른 애플리케이션은 작동하지 않음

• 현재 시스템 프록시만 활성화되어 있는지 확인합니다.
• 대상 애플리케이션이 프록시를 지원하는지 또는 TUN 처리가 필요한지 확인합니다.
• 프로세스별 분할 라우팅 규칙에서 해당 애플리케이션이 직접 연결로 설정되어 있는지 확인합니다.
• 애플리케이션 자체 DNS, QUIC 또는 고정 출구 정책으로 차이가 발생하는지 확인합니다.

연결은 안정적이지만 접속 결과가 예상과 다름

먼저 출구 지역을 확인한 다음 대상 웹사이트가 계정 지역, 캐시, 언어 설정 또는 브라우저 위치 정보에 따라 콘텐츠를 표시하는지 점검하세요. 노드는 처리 대상 트래픽의 네트워크 출구만 바꾸며 웹사이트 계정 정보를 자동으로 수정하지 않습니다. 특정 플랫폼이 현재 출구를 거부한다면 모든 결과를 프로토콜 탓으로 돌리기보다 적합한 지역이나 회선으로 바꿔 확인해야 합니다.

이 VPN 용어를 익히면 연결을 하나의 명확한 흐름으로 이해할 수 있습니다. 구독이 설정을 제공하고, 클라이언트가 노드를 해석하며, 프로토콜이 통신을 수립하고, 회선이 데이터를 전달하며, 분할 라우팅이 경로를 선택하고, DNS가 도메인을 조회하며, 출구가 기기를 대신해 대상에 접속합니다. 서비스를 선택하거나 문제를 해결할 때는 이 흐름을 따라 단계별로 확인하는 편이 특정 프로토콜 이름만 좇는 것보다 신뢰할 수 있습니다. 실제 사용법을 더 알아보려면 초보자 가이드와 전체 가이드를 확인하세요.