프로토콜 및 회선 기술 가이드

CHAPTER A / DECISION MODEL

먼저 프로토콜과 회선을 판단하는 기준 세우기

프로토콜은 전송 방식을, 회선은 실제 경로를 결정합니다

연결 품질을 이야기할 때 가장 흔한 오해는 프로토콜 이름을 속도와 동일시하는 것입니다. 프로토콜은 클라이언트가 데이터를 캡슐화하고 서버와 세션을 설정하며 신뢰성과 혼잡을 처리하는 방식을 정합니다. 반면 회선은 로컬 접속 지점에서 대상 서비스까지 어떤 네트워크를 거치고 어디에서 교환되며 우회하는지를 결정합니다. 최종 성능은 이 두 요소가 함께 만들어 냅니다. 현재 네트워크에 적합한 프로토콜이라도 회선이 혼잡하면 끊길 수 있고, 경로가 짧아도 약한 네트워크에서 프로토콜의 복구가 늦으면 멈춤이 발생합니다.

따라서 선택은 “어떤 프로토콜이 가장 빠른가”에서 시작해서는 안 되며, 먼저 사용 환경을 확인해야 합니다. 고정 광대역은 연결이 오래 유지되고 네트워크 전환이 적으므로 처리량과 피크 시간대 안정성이 중요합니다. 모바일 네트워크는 접속 방식이 바뀌므로 재연결 속도, 연결 마이그레이션과 백그라운드 리소스 사용량을 더 중시해야 합니다. 공용 Wi-Fi는 지터, 패킷 손실 또는 세션 타임아웃이 뚜렷할 수 있어 불연속 전송에서 프로토콜이 얼마나 잘 복구하는지 살펴봐야 합니다. 사용 상황을 정한 뒤에야 프로토콜 차이를 제대로 판단할 수 있습니다.

사용자 경험을 관찰 가능한 단계로 나누기

연결 경험은 도메인 확인, 진입점 연결, 프로토콜 핸드셰이크, 회선 전달, 대상 서비스 응답, 지속 전송의 연속된 단계로 나눌 수 있습니다. 페이지가 늦게 열리는 원인이 반드시 회선 처리량 부족인 것은 아닙니다. DNS 조회 대기나 반복되는 핸드셰이크 때문일 수도 있습니다. 영상은 빠르게 시작되지만 중간에 자주 버퍼링된다면 지속 처리량의 변동에 가까운 경우가 많고, 통화가 끊기듯 들리면 지터, 패킷 손실과 큐 누적을 우선 확인해야 합니다. 증상을 해당 단계와 연결하면 프로토콜을 무작정 바꾸는 것보다 원인을 찾기 쉽습니다.

테스트할 때는 변수도 통제해야 합니다. 먼저 기기, 접속 네트워크, 대상 서비스와 회선을 고정한 뒤 프로토콜만 바꾸고, 다음에는 프로토콜을 고정한 채 같은 지역의 회선만 바꿔 보세요. 프로토콜과 회선을 동시에 바꾸면 문제가 어느 계층에서 발생했는지 알 수 없습니다. 장기간 사용할 환경이라면 실제 사용 시간대에 반복해서 관찰해야 하며, 연결이 한 번 성공했는지만 봐서는 안 됩니다. 피크 시간대의 혼잡, 모바일 기지국 전환과 가정 내 다른 다운로드 작업은 한 번의 판단을 쉽게 왜곡합니다.

단일 지표를 최종 결론으로 삼지 않기

지연 시간은 상호작용 반응을 판단하는 데 유용하지만 다운로드 성능을 단독으로 나타내지는 않습니다. 대역폭은 지속 전송을 확인하는 지표지만 짧은 연결이 원활하게 설정되는지는 보여 주지 못합니다. 패킷 손실은 재전송과 멈춤을 설명할 수 있지만, 소량의 순간적 손실과 지속적인 손실의 영향은 다릅니다. 더 효과적인 방법은 지표를 실제 작업과 연결하는 것입니다. 웹과 업무 도구는 연결 설정과 응답, 영상은 지속 처리량과 변동, 음성은 지터와 큐, 파일 동기화는 장시간 안정성을 확인하세요.

프로토콜 선택은 한 번 정하면 끝나는 일이 아닙니다. 네트워크 상태, 기기 운영체제, 현재 지역과 대상 서비스가 모두 바뀔 수 있습니다. 고정 광대역에 적합한 조합이 출퇴근 중 모바일 네트워크에도 맞는 것은 아니며, 현재 지역에서 안정적인 회선도 다른 접속 네트워크에서는 다른 경로를 사용할 수 있습니다. 주 사용 조합과 예비 조합을 하나씩 정하고 각 조합에 맞는 상황을 기록하는 편이 이른바 만능 해답 하나만 찾는 것보다 안정적입니다. VPNJB는 100+ 국가 / 190+ 회선을 제공하므로 지역과 토폴로지로 범위를 좁힌 뒤 후보 회선의 프로토콜 성능을 비교하세요.

CHAPTER B / PROTOCOL FAMILY

주요 프로토콜의 설계 차이와 사용 범위

Shadowsocks: 단순한 구조, 회선 품질에 좌우됨

Shadowsocks의 핵심 특징은 구조가 비교적 단순하다는 점입니다. 데이터 캡슐화와 전달 경로를 이해하기 쉽고 클라이언트 구현도 대체로 성숙했습니다. 네트워크 상태가 안정적이고 기기 리소스가 제한되어 있으며 추가 처리 부담을 줄이고 싶은 환경에 적합합니다. 실제 경험은 하위 전송 방식과 회선 자체에 크게 좌우됩니다. 회선이 원활하면 연결 설정과 전송이 모두 깔끔하지만, 하위 경로에서 뚜렷한 패킷 손실이나 큐 누적이 발생하면 복구 속도는 사용 중인 전송 방식의 영향을 받습니다. Shadowsocks를 선택할 때는 프로토콜 이름보다 회선 안정성을 먼저 확인해야 합니다.

이 프로토콜이 모든 기기에서 자동으로 리소스를 덜 사용한다는 뜻은 아닙니다. 실제 사용량은 클라이언트 구현, 암호화 방식, 시스템 네트워크 스택과 동시 연결 수에도 좌우됩니다. 브라우저에서 여러 페이지를 열거나 동기화 도구가 많은 장기 연결을 유지하면 클라이언트가 관리해야 할 상태가 크게 늘어납니다. 유휴 상태에서는 정상인데 동시 접속 후 지연이 증가한다면 프로토콜 매개변수만 조정하지 말고 기기 부하, 가정용 라우터 큐와 회선 혼잡을 함께 점검하세요.

VMess와 VLESS: 세션 모델이 다르므로 전달 계층이 중요

VMess는 자체 세션 및 인증 설계를 갖추고 있어 다양한 전달 방식과 함께 사용할 수 있습니다. 유연한 만큼 구성 조합이 많으므로 문제를 해결할 때 실제 전달 계층을 명확히 해야 합니다. 같은 프로토콜 이름이라도 한 연결이 지속 세션 위에서 동작하고 다른 연결이 추가 애플리케이션 계층 캡슐화를 거치면 핸드셰이크 횟수, 헤더 오버헤드와 장애 양상이 달라질 수 있습니다. 연결이 느릴 때는 DNS 조회, 하위 연결과 프로토콜 인증 중 어디에서 시간이 걸리는지 먼저 확인하고 VMess 탓으로 뭉뚱그리지 마세요.

VLESS는 프로토콜 자체를 간결하게 유지하고 보안과 전송 기능을 외부 전달 계층에 맡기는 방향에 가깝습니다. 중복 기능을 줄일 수 있지만 서버와 클라이언트의 전달 설정이 일치해야 합니다. VLESS의 실제 성능도 고정된 값이 아닙니다. 어떤 전송 방식을 사용하는지, 회선이 우회하는지, 기기가 자주 네트워크를 전환하는지에 따라 결과가 달라집니다. 인증, 암호화와 전송의 역할을 명확히 나누고 싶은 구성에 적합하지만 각 계층의 기능을 이해해야 전달 계층 문제를 프로토콜 장애로 오해하지 않습니다.

Trojan: 성숙한 보안 세션 활용, 핸드셰이크와 연결 재사용에 주의

Trojan은 일반적으로 성숙한 보안 세션을 활용해 인증과 전송을 수행합니다. 구현 경로가 명확하고 기존 보안 전송 스택을 바로 활용할 수 있다는 점이 장점입니다. 반면 연결 설정에 하위 보안 핸드셰이크가 포함되므로 짧은 연결이 많을 때는 세션 재사용을 살펴봐야 합니다. 클라이언트가 연결을 계속 새로 만들고 적절히 재사용하지 않으면 페이지의 작은 리소스가 많을수록 핸드셰이크 대기가 커집니다. 장시간 전송에서는 이 고정 비용이 분산되므로 경험은 회선 처리량과 패킷 손실의 영향을 더 크게 받습니다.

Trojan을 점검할 때는 첫 접속과 이후 접속 사이에 뚜렷한 차이가 있는지 관찰할 수 있습니다. 첫 연결만 오래 기다리고 연결 후 지속 전송이 안정적이라면 DNS 조회, 핸드셰이크 또는 인증서 경로에 가까운 문제입니다. 시작은 빠르지만 지속 전송이 크게 흔들리면 회선과 혼잡을 분석해야 합니다. 기기 시간, 시스템 보안 구성 요소와 클라이언트 네트워크 권한도 핸드셰이크에 영향을 주므로 장애 처리를 회선 변경에만 국한해서는 안 됩니다.

Hysteria2와 TUIC: 변동이 큰 네트워크를 위한 전송 전략

Hysteria2와 TUIC는 변동이 크거나 패킷 손실이 발생하는 고대역폭·고지연 경로에서 전송을 조정하는 데 더 중점을 둡니다. 일반적으로 데이터그램 전송을 기반으로 하며 프로토콜 자체가 신뢰성, 혼잡 제어와 다중 데이터 처리를 담당합니다. 전통적인 신뢰성 바이트 스트림에 의존하는 방식과 비교하면 개별 데이터 단위의 손실을 더 유연하게 처리해 하나의 재전송 때문에 모든 논리 스트림이 막히는 상황을 줄일 수 있습니다. 그러나 유연하다고 해서 회선 품질을 무시해도 되는 것은 아닙니다. 지속적인 심각한 패킷 손실은 여전히 대역폭을 소모하고 기기의 처리 부담을 늘립니다.

이 두 유형의 프로토콜은 네트워크 변동이 크거나 지속 전송이 필요하고 접속 환경을 자주 전환하는 상황에 적합합니다. 시스템의 데이터그램 처리 능력, 클라이언트 구현과 네트워크 장비 호환성에 더 민감합니다. 일부 네트워크는 데이터그램 세션의 유휴 시간을 짧게 설정하므로 백그라운드 앱이 복귀할 때 상태를 다시 설정해야 할 수 있습니다. 모바일 기기가 대기 후 자주 잠시 연결을 잃는다면 송신 빈도를 단순히 높이지 말고 시스템 백그라운드 정책과 세션 유지 기능을 확인하세요. 과도한 유지 연결은 배터리와 데이터 사용량을 직접 늘립니다.

CHAPTER C / CONNECTION COST

연결 설정, 처리량과 리소스 사용량의 균형

연결이 빠르다고 지속 전송도 빠른 것은 아닙니다

사용자가 체감하는 “속도”에는 적어도 두 가지 과정이 포함됩니다. 하나는 요청을 시작한 뒤 첫 응답을 받을 때까지의 대기로, DNS 조회, 연결 설정, 프로토콜 핸드셰이크와 대상 서비스 응답의 영향을 받습니다. 다른 하나는 연결 후 지속되는 전송으로, 회선 용량, 혼잡 제어, 패킷 손실 복구와 기기 처리 능력의 영향을 받습니다. 웹 페이지는 짧은 요청이 많아 설정 비용이 드러나기 쉽고, 영상·파일 동기화·시스템 업데이트는 오래 지속되므로 처리량 변동이 더 잘 나타납니다. 선택할 때 어떤 과정을 최적화하려는지 먼저 정해야 합니다.

프로토콜 핸드셰이크가 적을수록 무조건 좋은 것은 아닙니다. 핸드셰이크는 인증, 키 협상과 기능 확인을 담당하므로 필요한 과정을 생략하면 보안 범위가 달라집니다. 합리적인 최적화 방향은 반복적인 연결 설정을 줄이고 이미 완료된 세션을 재사용하며, 네트워크가 바뀌지 않았을 때 클라이언트가 연결 상태를 유지하도록 하는 것입니다. 연결 실패 후 백오프 없이 계속 재시도하면 기기에서 배터리 소모, 발열과 네트워크 혼잡이 동시에 발생합니다. 성숙한 클라이언트는 재시도 간격을 제어하므로 사용자가 고빈도 수동 전환으로 장애를 키워서는 안 됩니다.

다중화의 이점과 헤드 오브 라인 블로킹

다중화는 여러 논리 요청을 더 적은 하위 세션에 넣어 반복적인 핸드셰이크와 연결 관리를 줄이며, 짧은 요청이 많은 웹과 업무 도구에 적합합니다. 그러나 한곳에 많이 모을수록 좋은 것은 아닙니다. 많은 논리 스트림이 하나의 신뢰성 전송을 공유할 때 하위 계층에서 패킷 손실이 발생하면 재전송을 기다리는 데이터가 다른 논리 스트림에도 영향을 줄 수 있는데, 이것이 흔히 말하는 헤드 오브 라인 블로킹입니다. 데이터그램형 프로토콜은 전송 계층에서 논리 스트림 간 대기를 줄일 수 있지만 애플리케이션 구현과 회선 큐의 영향은 여전히 받습니다.

다중화를 켠 뒤 가벼운 웹 페이지는 빨라졌지만 대용량 파일 전송의 변동이 커진다면 짧은 요청과 장기 연결을 나누어 테스트하세요. 종합적인 체감만 봐서는 안 됩니다. 다중화는 연결 수를 줄이지만 하나의 세션에 더 많은 트래픽을 집중시킬 수 있습니다. 가정용 라우터, 시스템 방화벽 또는 클라이언트 프로세스의 처리 능력이 제한적이면 집중된 트래픽이 병목에 더 빨리 도달합니다. 다중화 수준을 낮추거나 끈 뒤 회복된다면 원격 회선 용량이 아니라 로컬 리소스나 단일 세션 스케줄링에 문제가 있을 가능성이 큽니다.

암호화, 캡슐화와 기기 처리 능력

모든 암호화와 캡슐화에는 계산 비용이 필요하지만 최신 기기에서의 실제 차이를 프로토콜 이름만으로 판단할 수는 없습니다. 프로세서가 적절한 명령어를 지원하는지, 클라이언트가 시스템 최적화를 호출하는지, 데이터가 추가로 복사되는지, 로그 수준이 지나치게 높은지에 따라 사용량이 달라집니다. 데스크톱에서는 지속적인 고처리량 전송 중 프로세서 부하가 드러나기 쉽고, 모바일 기기에서는 발열, 클록 저하와 배터리 감소로 나타나는 경우가 많습니다. 기기 온도가 올라갈수록 네트워크 속도가 떨어진다면 기기 열 관리도 판단에 포함해야 합니다.

리소스 사용량은 규칙의 복잡도와도 관련이 있습니다. 클라이언트는 데이터를 보내기 전에 도메인, 주소 또는 앱을 기준으로 경로를 판단하는 경우가 많습니다. 중복 규칙, 서로 겹치는 조건과 계속 갱신되는 로컬 데이터베이스는 처리 부담을 늘립니다. 프로토콜 자체는 가벼워도 규칙 체인이 길면 결국 지연이 발생합니다. 문제를 점검할 때는 잠시 단순한 규칙을 사용해 기본 연결이 안정적인지 확인한 뒤 분할 라우팅을 단계적으로 복구하세요. 규칙을 복구할 때 문제가 재현된다면 서버 프로토콜을 계속 바꾸기보다 규칙 순서를 확인해야 합니다.

연결 재사용에도 정리 메커니즘이 필요합니다

세션을 오래 유지하면 설정 비용을 줄일 수 있지만 만료된 상태를 제때 정리하지 않으면 연결된 것처럼 보이지만 실제 요청은 통과하지 않는 반쪽짜리 상태가 될 수 있습니다. 모바일 기기가 절전 상태에서 복귀하거나 가정용 네트워크가 주소를 다시 할당하거나 라우터가 재시작된 뒤에는 기존 세션이 특히 쉽게 무효화됩니다. 신뢰할 수 있는 클라이언트는 네트워크 변화를 감지하고 필요한 연결을 다시 설정해야 합니다. 상태 아이콘은 정상인데 앱이 응답하지 않는다면 여러 회선을 연속으로 바꾸기보다 클라이언트에서 제어된 재연결을 한 번 수행하는 편이 문제 해결 단서를 보존하기 쉽습니다.

VPNJB는 100+ 국가 / 190+ 회선을 제공하지만, 후보 연결을 대량으로 동시에 유지해야 한다는 뜻은 아닙니다. 일상적인 사용에서는 대상 서비스의 위치와 토폴로지에 맞는 소수의 회선만 선택하면 됩니다. 후보가 너무 많으면 테스트 비용이 늘고 짧은 변동을 장기적인 차이로 오해하기 쉽습니다. 먼저 주 사용 지역을 정하고 같은 토폴로지 안에서 프로토콜을 비교한 다음 예비 지역 하나를 남겨 두면 연결 관리가 더 명확해집니다.

CHAPTER D / MOBILE ENERGY

모바일 배터리, 백그라운드와 네트워크 전환

배터리 소모는 깨우기, 재연결과 지속적인 처리에서 발생합니다

모바일 기기의 배터리 소모를 프로토콜 암호화 비용만으로 판단해서는 안 됩니다. 무선 모듈이 절전 상태에서 깨어나는 일, 백그라운드에서 계속 유지 신호를 보내는 일, 네트워크 변화 후 반복적으로 재연결하는 일, 클라이언트가 많은 규칙을 처리하는 일이 한 번의 데이터 암호화보다 배터리에 더 큰 영향을 주는 경우가 많습니다. 지속 다운로드 중에는 무선 모듈이 원래 활성 상태이므로 프로토콜 간 차이가 뚜렷하지 않을 수 있습니다. 반면 대기나 간헐적인 메시지 환경에서는 너무 잦은 소규모 패킷이 시스템의 저전력 상태 진입을 막아 체감 차이가 더 커집니다.

배터리 문제를 판단할 때는 전면에서 많은 데이터를 사용할 때와 백그라운드 대기를 구분해야 합니다. 전면에서 영상이나 파일을 전송하며 배터리가 줄어드는 것은 화면, 디코딩과 무선 전송 비용이 함께 포함된 결과입니다. 백그라운드에 뚜렷한 작업이 없는데도 계속 배터리를 사용한다면 유지 연결, 재시도와 앱 깨우기를 점검해야 합니다. 시스템 배터리 화면은 프로세스 단위의 집계만 제공하므로 특정 프로토콜의 문제를 직접 증명하지는 못하지만, 클라이언트가 활성 상태가 아니어야 할 때도 계속 실행되는지는 확인할 수 있습니다.

시스템 백그라운드 정책이 연결 상태를 바꿀 수 있습니다

Android 기기의 절전 정책, 제조사 백그라운드 관리와 앱 절전 기능은 클라이언트 프로세스를 일시 중지할 수 있습니다. 일반적인 현상은 화면을 잠근 뒤 연결이 끊기고 전면으로 돌아오면 자동으로 복구되는 것입니다. 먼저 클라이언트에 필요한 백그라운드 실행 권한이 있는지 확인한 뒤 시스템의 제한 앱 목록에 포함되었는지 점검하세요. 처음부터 유지 연결 빈도를 높이지 마세요. 프로세스가 시스템에 의해 완전히 일시 중지되면 추가 유지 신호를 보낼 수 없고, 프로세스가 복귀한 뒤 재시도가 한꺼번에 발생할 수 있습니다.

iOS는 백그라운드 네트워크 확장을 자체적으로 조정하므로 일반적으로 주 화면을 계속 전면에 둘 필요가 없습니다. 네트워크를 전환한 뒤 잠시 사용할 수 없다면 시스템 네트워크 확장이 경로 업데이트를 완료할 시간을 주세요. 계속 복구되지 않을 때만 클라이언트에서 연결을 끊었다가 다시 연결하세요. macOS와 Windows 노트북에서도 절전 복귀 문제가 발생할 수 있으며, 특히 덮개를 닫고 깨운 뒤 네트워크 전환까지 연속으로 일어날 때 두드러집니다. 이런 장애의 공통 점검 항목은 단순한 회선 교체가 아니라 네트워크 경로 변화입니다.

연결 마이그레이션은 모바일 환경에 적합하지만 경로를 다시 확인해야 합니다

일부 데이터그램형 프로토콜은 더 유연한 연결 마이그레이션을 지원합니다. 기기가 Wi-Fi에서 모바일 네트워크로 전환될 때 클라이언트가 논리 세션을 유지해 완전히 다시 설정하는 대기를 줄일 수 있습니다. 하지만 새 접속 네트워크는 다른 출구 경로, 최대 패킷 크기 제한 또는 세션 관리 규칙을 사용할 수 있으므로 마이그레이션에 성공했다고 이후 전송이 안정적이라는 뜻은 아닙니다. 네트워크 전환 후 계속 끊긴다면 기존 상태를 억지로 유지하지 말고 적극적으로 재연결해 새 경로를 다시 탐색하게 하세요.

전통적인 신뢰성 바이트 스트림은 주소가 바뀐 뒤 하위 연결을 다시 설정해야 하는 경우가 많습니다. 동작이 더 직관적입니다. 기존 연결이 무효화되고 새 연결이 다시 핸드셰이크합니다. 재설정 과정에서 잠시 멈출 수 있지만 문제를 좁히기 쉽습니다. 지속적인 통화나 원격 회의가 필요하다면 연결 마이그레이션을 잘 지원하는 프로토콜을 먼저 시도하고, 동작이 더 보수적인 예비 프로토콜도 준비하세요. 현재 네트워크에서 데이터그램 전송이 불안정하다면 매개변수를 계속 조정하는 것보다 전통적인 전달 방식으로 돌아가는 편이 효과적일 수 있습니다.

앱별 프록시는 불필요한 트래픽을 줄일 수 있습니다

모바일 기기에서 앱별 프록시를 지원한다면 국제 회선이 필요한 앱만 가속 경로로 보내 로컬 서비스와 시스템 백그라운드 작업에서 발생하는 불필요한 트래픽을 줄일 수 있습니다. 회선 부담을 낮추는 동시에 특정 앱의 문제가 프록시 경로에서 비롯되는지도 확인하기 쉽습니다. 설정할 때는 앱 간 호출 관계에 주의해야 합니다. 예를 들어 주 앱이 브라우저를 호출해 로그인하는 경우 두 앱의 경로가 다르면 이동 후 상태가 일치하지 않을 수 있습니다. 이런 상황에서는 관련 앱을 잠시 같은 경로로 설정한 뒤 다시 확인하세요.

VPNJB는 기기 수 제한이 없어 Windows / macOS / iOS / Android / Linux 환경에 맞는 구성을 각각 설정하기 좋습니다. 기기 수 제한이 없다고 모든 기기에서 같은 프로토콜을 사용해야 하는 것은 아닙니다. 고정 데스크톱은 안정적인 장기 연결을 우선할 수 있고, 모바일 기기는 네트워크 전환 후 복구와 백그라운드 동작을 더 중시할 수 있습니다. 모든 단말에 같은 매개변수를 복사하기보다 기기별 주 사용 구성을 명확히 저장하는 편이 관리하기 쉽습니다.

CHAPTER E / ROUTE TOPOLOGY

직결·중계·전용 회선의 경로 차이

직결: 구조는 가장 짧지만 공용 네트워크 라우팅의 영향을 받음

직결은 클라이언트가 로컬 네트워크를 통해 서비스 제공자가 관리하는 추가 접속 전달 계층 없이 대상 진입점에 직접 도달하는 방식입니다. 구조가 단순하고 추가 중계에 따른 고정 처리 비용이 없다는 장점이 있습니다. 로컬 통신망에서 진입점으로 향하는 경로가 좋다면 지연과 처리량이 모두 직접적으로 나타날 수 있습니다. 반면 공용 네트워크 라우팅은 여러 네트워크가 함께 결정하므로 시간, 지역과 접속 방식에 따라 달라질 수 있으며, 서비스 제공자가 로컬에서 진입점까지의 구간을 통제하기 어렵다는 한계가 있습니다.

직결은 로컬 네트워크와 대상 지역 사이의 상호 연결이 원래 양호한 환경에 적합합니다. 판단할 때는 지리적 거리만 보지 마세요. 지도상의 직선거리보다 네트워크 간 교환 관계가 더 중요합니다. 인접 지역도 멀리 있는 교환 지점을 거칠 수 있고, 더 먼 지역이 오히려 원활한 백본 경로를 제공할 수 있습니다. 직결이 낮에는 안정적이지만 피크 시간대에 크게 흔들린다면 공용 네트워크 연동이나 공유 출구에서 문제가 발생했을 가능성이 있습니다. 같은 지역의 다른 진입점으로 바꾸거나 중계를 사용하면 안정성이 좋아질 수 있습니다.

중계: 먼저 접속 지점에 들어간 뒤 출구로 전달

중계 회선에서는 클라이언트가 먼저 가까운 접속 지점이나 상호 연결이 좋은 지점에 연결한 다음, 해당 지점이 출구로 데이터를 전달합니다. 중계의 가치는 물리적 거리를 없애는 것이 아니라 품질이 불확실한 공용 라우팅 구간을 관리 가능한 중간 경로로 대체하는 데 있습니다. 좋은 중계는 우회와 네트워크 간 교환의 불안정성을 줄일 수 있지만 유지 관리가 필요한 단계가 하나 늘어납니다. 접속 지점, 전달 경로 또는 출구 중 어느 한 곳이라도 혼잡하면 최종 경험에 영향을 줄 수 있습니다.

중계는 로컬에서 대상 지역으로의 직결이 불안정하지만 접속 지점까지의 경로는 좋은 환경에 적합합니다. 선택할 때는 진입 지역과 출구 지역을 구분해야 합니다. 진입 지역은 로컬 접속 품질을, 출구 지역은 대상 서비스에 표시되는 위치와 이후 경로를 결정합니다. 출구 이름만 보고 선택하면 전반부 경로를 놓칠 수 있습니다. VPNJB의 상세 회선 정보는 회선 페이지에서 확인할 수 있습니다. 비교할 때는 같은 출구 지역에서 회선 유형을 달리해 관찰하고, 여러 지역의 변수를 동시에 바꾸지 마세요.

전용 회선: 관리 가능한 경로를 중시하지만 종단 네트워크까지 무시하는 것은 아님

전용 회선은 일반적으로 중간의 핵심 구간에 더 통제하기 쉬운 전송 자원을 사용하는 방식을 뜻하며, 공용 네트워크 교환의 불확실성을 줄이는 것이 목적입니다. 지속적인 업무, 장시간 동기화, 영상 재생과 피크 시간대 변동에 민감한 환경에 더 적합합니다. 전용 회선에도 사용자의 로컬 네트워크에서 접속 지점까지, 출구에서 대상 서비스까지의 종단 네트워크가 포함되므로 전체 경로를 완전히 독점한다고 이해해서는 안 됩니다. 가정용 Wi-Fi 간섭, 로컬 광대역 혼잡과 대상 서비스 자체의 부하도 최종 성능에 영향을 줍니다.

IEPL 전용 회선은 한 번의 최고 속도보다 안정성과 경로 일관성을 중심으로 판단해야 합니다. 같은 업무가 여러 사용 시간대에도 비슷한 응답과 처리량을 유지한다면 경로 변동이 작다는 뜻입니다. 속도 측정만 빠르고 실제 앱에서는 계속 멈춘다면 앱 분할 라우팅, DNS 위치와 대상 서비스 연결을 확인해야 합니다. 전용 회선은 중간 경로를 개선할 수 있지만 올바른 클라이언트 설정을 대신할 수 없고 단말 성능의 병목도 없애지 못합니다.

출구 위치는 가장 가까운 곳이 아니라 업무에 맞춰 선택해야 합니다

웹, AI 도구, 스트리밍과 기업 서비스는 인프라가 서로 다른 지역에 분포합니다. 가장 가까운 출구는 상호작용 응답에 유리한 경우가 많지만, 대상 서비스가 주로 다른 지역에서 접속된다면 가까운 출구를 사용해도 후반부에서 다시 지역 간 이동이 발생할 수 있습니다. 더 합리적인 방법은 먼저 업무가 도달해야 할 지역을 정한 뒤 로컬에서 해당 지역까지의 회선을 비교하는 것입니다. 여러 지역의 서비스를 동시에 이용해야 한다면 분할 라우팅으로 업무 유형마다 맞는 출구를 사용하고, 모든 트래픽을 하나의 원격 위치로 보내지 않는 편이 좋습니다.

회선을 선택할 때는 안정적인 전환도 고려해야 합니다. 출구를 자주 바꾸면 앱이 인식하는 네트워크 환경이 달라져 일부 로그인 세션, 콘텐츠 지역과 보안 인증이 영향을 받을 수 있습니다. 일상적인 사용에서는 주 출구를 가급적 고정하고 회선에 문제가 확인될 때만 전환하세요. 업무용 앱은 특히 경로를 일정하게 유지해야 합니다. 출장 중 호텔 네트워크와 업무 소프트웨어를 준비하는 방법은 출장 VPN 선택과 네트워크 준비에서 확인할 수 있습니다.

CHAPTER F / LOSS AND CONGESTION

패킷 손실, 지터와 피크 시간대 혼잡의 원인

패킷 손실은 하나의 장애가 아닙니다

패킷 손실은 무선 접속, 가정용 라우터, 통신망 교환, 지역 간 백본, 중계 노드 또는 대상 서비스 진입점에서 발생할 수 있습니다. Wi-Fi 간섭으로 인한 손실은 보통 거리, 채널 경쟁과 기기 위치의 영향을 받습니다. 라우터 큐 오버플로는 가정에서 업로드와 다운로드를 동시에 수행할 때 자주 발생하고, 공용 네트워크 경로의 손실은 특정 방향이나 경로 유형에만 영향을 줄 수 있습니다. “패킷 손실”이라는 말만으로는 책임 지점을 판단할 수 없으며 발생 시간과 업무 조건을 함께 봐야 합니다.

순간적인 패킷 손실과 지속적인 패킷 손실은 체감이 다릅니다. 짧은 순간의 손실은 페이지 리소스 한 번의 재전송이나 통화의 찰나의 끊김을 유발할 수 있지만, 프로토콜이 복구하면 계속 진행할 수 있습니다. 지속적인 손실은 혼잡 제어를 반복적으로 작동시켜 처리량을 점차 낮추고 재전송 트래픽을 늘립니다. 데이터그램형 프로토콜은 일부 헤드 오브 라인 블로킹을 피할 수 있지만 신뢰성이 필요한 업무에서 손실된 데이터는 결국 복구해야 합니다. 어떤 프로토콜도 실제로 사라진 데이터를 자동으로 없던 일로 만들 수 없으며 감지, 재전송과 조정 방식을 바꿀 뿐입니다.

지터는 평균 대기가 아닌 지연 변화의 지표입니다

음성, 원격 데스크톱과 상호작용 앱은 지터에 민감합니다. 평균 지연이 허용할 만해도 데이터 도착 간격이 들쭉날쭉하면 수신 측에서 재생을 매끄럽게 만들기 위해 더 큰 버퍼가 필요하고, 버퍼가 커지면 상호작용 대기도 늘어납니다. 주문형 영상은 콘텐츠를 오래 버퍼링하므로 짧은 지터에는 비교적 관대하지만, 지속적인 변동은 버퍼를 소모해 결국 멈춤을 유발합니다. 따라서 같은 회선이 영상에는 적합해도 실시간 통화에는 적합하지 않을 수 있습니다.

지터는 큐 변화에서 발생하는 경우가 많습니다. 네트워크가 유휴 상태일 때는 데이터가 빠르게 통과하지만 다른 작업이 업로드를 시작하면 라우터나 상위 장비에서 대기하면서 지연이 갑자기 높아집니다. 대용량 작업을 멈추면 다시 정상으로 돌아오는 현상은 고정된 고지연보다 한 번의 테스트로 발견하기 어렵습니다. 점검할 때는 가정용 백업, 시스템 업데이트, 클라우드 동기화 또는 다른 기기의 활동과 문제가 동시에 발생하는지 확인하세요. 연관성이 있다면 먼저 로컬 큐를 제어한 뒤 원격 회선을 평가해야 합니다.

피크 시간대는 공유 자원 경쟁의 결과입니다

피크 시간대 성능 저하는 보통 공유 네트워크에서 동시에 사용하는 양이 늘어나기 때문에 발생합니다. 혼잡 지점은 로컬 접속망, 네트워크 간 교환, 서비스 제공자의 접속 지점, 중계 경로와 출구일 수 있습니다. 같은 출구 지역을 사용하는 회선이라도 서로 다른 접속 및 백본 경로를 거칠 수 있으므로 피크 시간대 성능이 항상 같지는 않습니다. 전용 회선은 일부 중간 구간의 불확실성을 낮출 수 있지만 로컬 접속과 대상 서비스는 여전히 공유 자원을 사용할 수 있습니다.

피크 혼잡을 확인하려면 비교가 필요합니다. 모든 회선과 로컬 직접 접속 업무가 동시에 느려진다면 먼저 로컬 접속을 점검하세요. 특정 지역의 여러 회선만 떨어진다면 해당 지역으로 향하는 공용 경로가 혼잡할 수 있습니다. 한 회선만 비정상이라면 그 회선의 진입점이나 중계 상태에 가까운 문제입니다. 문제가 발생했을 때 여러 프로토콜을 무작정 전환하면 회선과 프로토콜 변수가 동시에 바뀝니다. 먼저 같은 프로토콜·같은 지역의 다른 회선으로 바꾼 뒤 프로토콜 변경 여부를 판단하세요.

혼잡 제어는 효율과 공정성 사이의 균형이 필요합니다

혼잡 제어는 확인 응답, 패킷 손실과 지연 변화를 바탕으로 전송 속도를 조절합니다. 지나치게 공격적으로 동작하면 짧은 시간에 큐를 더 많이 점유해 지터와 패킷 손실을 늘릴 수 있고, 지나치게 보수적이면 고지연 경로의 용량을 충분히 활용하지 못할 수 있습니다. 프로토콜마다 판단 방식이 달라 같은 회선에서도 처리량 곡선이 달라질 수 있습니다. 하지만 모든 알고리즘은 실제 용량의 제약을 받습니다. 매개변수가 존재하지 않는 대역폭을 만들어 내지는 않으며, 짧은 최고 속도를 위해 회선을 계속 가득 채워서도 안 됩니다.

사용자 입장에서는 업무의 안정성을 더 중요하게 봐야 합니다. 파일 동기화는 속도가 조금씩 변해도 계속 진행되면 괜찮지만, 통화는 전송 속도가 일정한 편이 좋고 웹은 짧은 요청이 제때 완료되어야 합니다. 선택할 때는 프로토콜의 조정 특성을 업무에 맞춰야 하며 하나의 속도 측정 결과로 모든 상황을 판단해서는 안 됩니다. VPNJB에서 현재 이용 가능한 지역과 회선 유형을 확인하려면 회선 목록으로 이동한 뒤 이 장의 방법에 따라 후보를 좁혀 보세요.

CHAPTER G / SCENARIO SELECTION

사용 상황에 맞춰 프로토콜과 회선 선택하기

웹, 이메일과 일상 업무

웹과 이메일은 짧은 연결, 작은 리소스와 백그라운드 동기화가 많으므로 연결 설정의 안정성, 신속한 DNS 조회와 정상적인 세션 재사용이 중요합니다. 고정 광대역 환경에서는 먼저 동작이 성숙하고 장애 범위가 명확한 Shadowsocks, Trojan 또는 VLESS를 사용한 뒤 로컬에서 진입점까지 안정적인 중계나 전용 회선을 조합해 볼 수 있습니다. 첫 페이지 로딩만 느리고 이후 정상이라면 DNS 조회와 핸드셰이크를 먼저 확인하세요. 업무 도구가 오래 온라인 상태인 뒤 응답하지 않는다면 세션 만료와 클라이언트 재연결을 중점적으로 점검해야 합니다.

국제 업무 소프트웨어는 로그인, 메시지, 파일과 음성·영상 서비스에 동시에 연결하므로 하나의 앱 이름 뒤에 여러 대상이 있을 수 있습니다. 분할 라우팅 규칙이 주 도메인만 포함하면 일부 기능이 다른 경로를 사용해 메시지는 정상인데 파일이 실패하거나 웹은 되는데 통화가 안 되는 현상이 발생할 수 있습니다. 먼저 전체 프록시 경로로 앱 전체를 확인한 뒤 규칙을 단계적으로 좁혀 가세요. 단기 출장을 앞두고는 호텔에 도착한 뒤 시스템 권한을 처리하지 않도록 클라이언트 로그인과 구독 가져오기를 미리 완료해야 합니다.

영상 재생과 스트리밍

주문형 영상은 지속 처리량과 변동 제어를 더 중시합니다. 재생은 빠르게 시작되지만 중간에 버퍼링된다면 지속 용량이나 혼잡 복구에 문제가 있을 가능성이 큽니다. 처음부터 시작되지 않는다면 출구 지역, DNS 위치 또는 서비스 지원과 관련될 수 있습니다. 회선을 선택할 때는 먼저 콘텐츠 지역을 맞춘 뒤 같은 지역에서 중계와 전용 회선을 비교하세요. 프로토콜은 안정적인 네트워크라면 전통적인 신뢰성 전송을 사용할 수 있고, 변동이 크다면 Hysteria2 또는 TUIC의 복구 성능을 비교해 볼 수 있습니다.

스트리밍 성능은 속도 측정 페이지만으로 판단할 수 없습니다. 속도 측정 대상은 콘텐츠 전송 노드와 다른 네트워크에 있을 수 있고 경로도 다릅니다. 실제 콘텐츠를 재생해 시작 속도, 화질 유지와 재생 위치를 이동한 뒤 복구되는지 확인하는 편이 더 정확합니다. 특정 플랫폼에서만 문제가 발생한다면 전체 네트워크를 바꾸지 말고 해당 플랫폼을 지원하는 회선을 확인하세요. Netflix, HBO 등의 지역 및 재생 문제는 스트리밍 지원 안내에서 계속 확인할 수 있습니다.

AI 도구와 장시간 응답 작업

AI 도구는 짧은 요청뿐 아니라 긴 스트리밍 응답을 유지하는 작업도 포함합니다. 연결 설정은 첫 응답까지의 대기에 영향을 주고, 회선 안정성은 출력 중단 여부에 영향을 줍니다. 선택할 때는 먼저 출구 지역과 서비스 이용 가능 여부를 확인한 뒤 상호작용 지연을 고려하세요. 출구를 자주 바꾸면 로그인 환경이 달라질 수 있으므로 일상적인 사용에서는 주 회선을 고정하는 것이 좋습니다. 텍스트 응답은 정상인데 파일 업로드가 실패한다면 업로드 방향의 큐, 파일 크기 제한과 앱 분할 라우팅을 따로 확인하세요.

장시간 응답이 중단되었다고 반드시 프로토콜 연결이 끊긴 것은 아닙니다. 브라우저 절전, 모바일 시스템의 백그라운드 제한, 서버 측 세션 타임아웃과 네트워크 전환도 페이지 연결을 종료할 수 있습니다. 같은 회선을 유지한 채 다른 브라우저나 데스크톱 기기와 비교해 보세요. 모바일 기기에서 화면을 잠근 뒤에만 중단된다면 모바일 백그라운드 장으로 돌아가야 합니다. VPNJB의 AI 이용 경로 안내는 AI 가속 안내에 모아 두었으며, 이 페이지에서는 전송 계층을 판단합니다.

실시간 통화, 원격 데스크톱과 상호작용 업무

실시간 업무는 최고 대역폭보다 지터와 큐 대기에 더 민감합니다. 경로가 안정적이고 교환 단계가 적은 회선을 우선 선택하며, 가정용 네트워크에서 대규모 업로드를 동시에 진행하지 마세요. 데이터그램형 프로토콜은 일반적으로 실시간 데이터를 독립적으로 처리하는 데 적합하지만 현재 네트워크가 데이터그램 전송을 안정적으로 지원해야 합니다. 통화가 일정한 주기로 끊긴다면 Wi-Fi 간섭과 큐를 확인하고, 모바일 네트워크 전환 중 끊긴다면 연결 마이그레이션과 앱 자체의 재연결 기능을 살펴보세요.

원격 데스크톱에서는 화면 업데이트와 입력 피드백이 서로 영향을 줍니다. 높은 처리량이 입력 지연을 보완하지 못하며 버퍼가 지나치게 크면 조작이 둔하게 느껴질 수 있습니다. 회선을 선택할 때는 먼저 인접 지역의 진입점을 비교한 뒤 원격 호스트 위치에 맞춰 출구를 조정하세요. 전용 회선은 중간 경로의 변동을 줄이고 싶은 환경에 적합하지만 단말 인코딩, 원격 호스트 부하와 로컬 디스플레이도 체감에 영향을 줍니다. 화면 멈춤을 모두 네트워크 탓으로 돌리지 마세요.

장기간 고정 사용과 임시 출장

장기간 고정 사용에는 안정적인 구성을 만드는 것이 적합합니다. 주 출구를 정하고 프로토콜을 기록하며 예비 회선을 남겨 두고 의미 없는 전환은 줄이세요. 임시 출장에서는 호텔 Wi-Fi, 공용 네트워크와 모바일 접속의 변화를 고려하고 복구 성능이 좋은 프로토콜과 오프라인에서도 확인할 수 있는 안내를 미리 준비해야 합니다. VPNJB는 이메일 주소 없이 사용자 이름과 비밀번호만으로 가입할 수 있으며, 요금제는 기기 수 제한을 두지 않아 출발 전에 여러 기기를 준비하기 편리합니다.

사용량은 실제 업무에 맞춰 선택해야 합니다. 월간 구독은 ¥9.9/월에 60GB, ¥18/월에 250GB, ¥28/월에 500GB가 포함되며, 데이터는 개통일을 기준으로 매월 초기화되고 중간 업그레이드 차액은 남은 일수에 따라 계산됩니다. 데이터 패키지는 ¥158/300GB, ¥358/1000GB, ¥658/3000GB이며 모두 사용할 때까지 유효하고 만료되지 않습니다. 자세한 선택과 결제 방법은 요금제 페이지에서 확인할 수 있습니다. 결제는 Alipay / WeChat Pay / USDT를 지원하며 7일 무조건 환불을 제공합니다.

CHAPTER H / VERIFICATION

반복 가능한 검증 및 문제 해결 절차 만들기

환경을 기록한 뒤 변경을 시작하세요

효과적인 문제 해결은 기록에서 시작합니다. 최소한 기기 플랫폼, 접속 네트워크, 현재 지역, 출구 지역, 회선 유형, 프로토콜 이름, 문제가 발생한 앱과 사용 시간대를 확인해야 합니다. 정보를 많이 모으는 것이 목적이 아니라 매번 같은 조건으로 비교하기 위한 것입니다. 무엇을 바꿨는지조차 확인할 수 없다면 이후 결과를 재현할 수 없습니다. 먼저 현재 정상 작동하는 구성을 기준으로 보존한 뒤 후보 구성을 복사해 수정하는 것이 좋습니다.

문제 설명은 관찰 가능한 동작으로 작성해야 합니다. 예를 들어 “웹 페이지를 연 뒤 첫 응답이 오래 오지 않음”, “영상은 정상적으로 시작되지만 계속 재생하면 버퍼링됨”, “기기 화면을 잠갔다가 해제하면 앱이 인터넷에 연결되지 않음”은 “회선이 느림”보다 분석하기 쉽습니다. 동작을 구체적으로 쓰면 연결 설정, 지속 전송 또는 백그라운드 복구 단계와 연결할 수 있고 다른 기기에서 재현하기도 쉽습니다. 특정 앱에서만 문제가 발생한다면 먼저 유사한 앱과 비교해 앱 경로 문제인지 전체 연결 문제인지 판단하세요.

네트워크 계층별로 범위를 좁혀 가세요

첫 단계는 로컬 네트워크 점검입니다. 기기에서 자주 사용하는 로컬 서비스에 직접 접속할 수 있는지 확인하고 업로드나 다운로드를 점유하는 작업을 중지하세요. 가능하다면 Wi-Fi와 유선 연결도 비교합니다. 두 번째는 클라이언트 상태 점검으로, 시스템 권한, 가상 인터페이스와 라우팅이 적용되었는지 확인합니다. 세 번째는 프로토콜을 유지한 채 같은 지역의 회선을 바꾸는 것입니다. 네 번째는 회선을 유지한 채 프로토콜을 바꾸는 것입니다. 매번 하나의 조건만 바꾸고 원래의 업무 동작을 반복하세요.

같은 기기에서 모든 회선이 실패하지만 다른 기기에서는 정상이라면 기기 권한, 시스템 네트워크 스택 또는 클라이언트 상태에 가까운 문제입니다. 같은 접속 네트워크에서 모든 기기가 실패하고 다른 네트워크로 바꾸면 복구된다면 로컬 라우터나 접속 경로를 확인해야 합니다. 특정 출구 지역에서만 문제가 발생한다면 해당 지역의 다른 회선 유형을 비교하세요. 이런 분기를 통해 장애 범위를 전체 서비스에서 기기, 접속, 프로토콜, 회선 또는 대상 서비스로 좁힐 수 있습니다.

DNS 조회, 라우팅과 앱 캐시를 구분하세요

도메인 조회는 앱이 처음 연결을 시도할 위치를 결정합니다. 조회 결과는 로컬에서 얻었지만 트래픽은 원격 출구로 나가면 대상 서비스가 출구에 적합하지 않은 주소를 할당할 수 있고, 반대로 원격 조회가 로컬 직결 업무에 영향을 줄 수도 있습니다. 웹 페이지는 열리지만 콘텐츠가 완전히 로드되지 않는다면 주 도메인과 리소스 도메인이 서로 다른 경로를 사용하고 있을 가능성이 있습니다. 점검할 때는 잠시 통합 라우팅으로 전체 페이지를 확인한 뒤 분할 라우팅을 복구하고 누락된 규칙을 확인하세요.

앱 캐시는 기존 연결과 이전 조회 결과를 보존할 수 있습니다. 회선을 바꾼 직후 테스트하면 앱이 이전 세션을 계속 재사용해 결과가 달라지지 않은 것처럼 보일 수 있습니다. 관련 앱을 완전히 종료한 뒤 다시 열거나 새 브라우저 세션으로 비교해 보세요. 시스템 클라이언트를 전환한 뒤에는 라우팅 테이블과 네트워크 확장이 업데이트될 때까지 기다린 후 테스트해야 합니다. 짧은 시간에 여러 회선을 연속으로 누르지 마세요. 앱, 시스템과 클라이언트의 상태 갱신 속도는 서로 다릅니다.

재연결할 때와 회선을 바꿀 때

기기가 네트워크를 전환했거나 절전에서 복귀했거나 상태 아이콘은 정상인데 요청에 응답하지 않는다면 먼저 제어된 재연결을 수행하세요. 같은 회선이 특정 시간대에 계속 흔들리고 로컬 네트워크는 정상이라면 같은 지역의 회선으로 바꿉니다. 여러 동종 회선에서 비슷한 문제가 나타날 때에만 다른 토폴로지를 비교하세요. 데이터그램 호환성, 전통적인 신뢰성 전송의 헤드 오브 라인 블로킹 또는 모바일 연결 마이그레이션을 명확히 가리키는 증상이 아니라면 프로토콜 변경은 경로 확인 뒤로 미루는 것이 좋습니다.

재연결 후 복구되었다고 근본 원인을 찾은 것은 아닙니다. 한 번의 재연결로 프로토콜 세션, 시스템 라우팅, DNS 상태와 앱 연결이 동시에 새로 고쳐지기 때문입니다. 문제가 반복된다면 어느 계층의 상태가 만료되었는지 추가로 판단해야 합니다. 다음에 문제가 발생하면 먼저 앱만 다시 시작하고, 그다음 클라이언트만 재연결한 뒤, 마지막에 기기를 재시작해 보세요. 복구 동작이 작을수록 실제로 효과가 있었던 단계를 찾기 쉽고 지원 담당자에게도 명확한 정보를 제공할 수 있습니다.

검증 결과를 안정적인 구성으로 전환하기

문제 해결이 끝나면 주 사용 조합이 적합한 상황과 예비 조합을 언제 사용할지 기록해야 합니다. 예를 들어 고정 업무에는 전용 회선과 동작이 성숙한 프로토콜을 사용하고, 모바일 이동에는 네트워크 전환 복구가 유연한 프로토콜을 사용하며, 영상 업무에는 콘텐츠 지역에 맞는 출구를 선택할 수 있습니다. 기록은 복잡할 필요가 없습니다. “현재 왜 이렇게 선택했는가”와 “어떤 증상이 나타나면 전환하는가”에 답할 수 있으면 됩니다. 이렇게 하면 시간이 지난 뒤 처음부터 다시 시행착오를 겪는 일을 줄일 수 있습니다.

구성 관리에는 더 이상 작동하지 않는 규칙과 중복 후보를 제때 삭제하는 일도 포함됩니다. 회선이 많다고 일상 목록까지 길어야 하는 것은 아닙니다. VPNJB는 100+ 국가 / 190+ 회선을 제공하므로 실제 사용에서는 지역, 업무와 토폴로지로 필터링할 수 있습니다. 클라이언트와 구독은 사용자 패널에서 가져오고 정적 설치 패키지 링크나 출처가 불분명한 구독 내용은 사용하지 마세요. macOS를 처음 사용하는 독자는 Mac VPN 설치 및 권한 가이드를 참고할 수 있습니다. 계정과 구독을 보관하는 방법은 VPN 보안 기초에서 확인하세요.