이 VPN 초보자 완벽 가이드는 단편적인 정의에서 시작하지 않습니다. 브라우저가 요청을 보내고, 클라이언트가 규칙을 적용하며, 회선이 데이터를 전달하고, 대상 웹사이트가 콘텐츠를 반환하는 과정을 따라 주요 용어의 관계를 설명합니다. 이 흐름을 이해하면 “구독 업데이트 실패”, “노드는 선택되지만 웹페이지가 열리지 않음”, “전체 모드와 규칙 모드의 차이” 같은 문제에서 어느 단계를 확인해야 하는지 알 수 있습니다.
업계 용어에서는 계정, 구독, 노드, 회선, 프로토콜을 서로 혼용하는 경우가 많습니다. 모두 연결과 관련된 것처럼 보이지만 실제 역할은 다릅니다. 계정은 서비스 설정을 받을 수 있는지 결정하고, 구독은 설정을 배포하며, 노드는 선택 가능한 접속 또는 출구를 나타냅니다. 프로토콜은 클라이언트와 서버가 데이터를 주고받는 방식을 정하고, 트래픽 분할 규칙은 어떤 요청을 이 경로로 보낼지 결정합니다. 한 단계가 정상이라고 해서 나머지 단계까지 반드시 정상인 것은 아닙니다.
웹사이트 접속 과정을 따라 전체 경로 이해하기
프록시나 VPN 서비스에 연결하지 않은 상태에서는 브라우저가 먼저 시스템에 설정된 DNS 리졸버에 도메인을 조회해 대상 주소를 얻은 뒤, 로컬 네트워크를 통해 직접 연결하는 경우가 일반적입니다. 클라이언트를 켜면 요청이 시스템 프록시, 가상 네트워크 인터페이스 또는 앱 내 프록시에 먼저 전달될 수 있으며, 이후 트래픽 분할 규칙에 따라 직결 또는 중계가 선택됩니다. 중계가 필요한 트래픽은 선택한 프로토콜로 캡슐화되어 노드나 중계 진입점으로 전송되고, 그다음 대상 서비스에 접속합니다.
반환 데이터는 반대 방향으로 클라이언트에 도착하고, 클라이언트가 캡슐화를 해제한 뒤 브라우저나 앱에 전달합니다. 웹페이지가 열리는지는 구독 설정과 노드 상태뿐 아니라 로컬 네트워크, DNS 결과, 대상 웹사이트 정책, 기기 시간, 클라이언트 권한, 회선 품질의 영향도 받습니다. 따라서 “노드 선택 가능”은 설정이 목록에 표시된다는 뜻일 뿐, 전체 접속 경로가 성공적으로 검증되었다는 의미는 아닙니다.
| 용어 | 주요 역할 | 혼동하지 말아야 할 대상 | 주요 확인 위치 |
|---|---|---|---|
| 계정 | 요금제, 구독 및 클라이언트 진입점 이용 | 특정 노드 또는 프로토콜 | 계정 패널 및 요금제 상태 |
| 구독 | 노드와 관련 설정을 클라이언트에 배포 | 지속적으로 유지되는 네트워크 연결 | 구독 업데이트 시간 및 가져오기 결과 |
| 노드 | 클라이언트에서 선택할 수 있는 접속 설정 제공 | 전체 물리 회선의 성능 보장 | 지역, 프로토콜 및 연결 로그 |
| 프로토콜 | 데이터 캡슐화, 인증 및 전송 방식 정의 | 노드가 위치한 국가 또는 지역 | 클라이언트 지원 범위 및 서버 설정 |
| 트래픽 분할 규칙 | 요청을 직결, 중계 또는 차단할지 결정 | 회선 자체의 속도 등급 | 규칙 모드, 매칭 기록 및 DNS 설정 |
문제를 해결할 때는 데이터 경로를 따라 범위를 단계적으로 좁혀 갈 수 있습니다. 구독이 업데이트되지 않으면 먼저 계정과 구독 주소를 확인합니다. 설정은 가져왔지만 노드 연결에 실패한다면 프로토콜 호환성, 기기 시간, 로컬 네트워크를 살펴봅니다. 노드가 연결되었는데 일부 웹사이트만 이상하다면 DNS, 트래픽 분할 매칭, 대상 서비스 자체를 확인해야 하며 구독을 반복해서 다시 가져오는 것만으로 해결하려 해서는 안 됩니다.
구독 링크는 일반 다운로드 주소가 아닙니다
구독은 보통 클라이언트가 읽을 수 있는 주소 형태로 제공됩니다. 클라이언트가 해당 주소에 요청을 보내면 노드 이름, 서버 주소, 포트, 인증 정보, 프로토콜 매개변수, 규칙 제공자 등의 설정을 받아 선택 가능한 설정 목록으로 변환합니다. 클라이언트마다 허용하는 구독 형식이 다를 수 있으므로, 같은 주소라도 모든 클라이언트가 바로 인식한다고 볼 수 없습니다.
구독 링크는 공개적으로 공유할 웹페이지 링크라기보다 설정을 지속적으로 가져오는 인증 정보에 가깝습니다. 이를 공개 검색창, 스크린샷, 로그에 복사하면 다른 사람이 계정과 관련된 연결 설정을 읽을 수 있습니다. 구독이 유출되었다면 클라이언트에서 로컬 기록만 삭제하기보다 먼저 서비스 패널에서 재설정 방법을 찾아야 합니다. 로컬 설정을 삭제해도 이미 유출된 주소가 자동으로 무효화되지는 않습니다.
가져오기 전후에 확인할 사항
- ✅ 계정 패널에서 구독 진입점을 확인하고 현재 요금제가 유효한지 점검합니다.
- ✅ 클라이언트가 해당 구독 형식을 지원하는지 확인하고, 프로토콜 이름만으로 호환성을 추측하지 않습니다.
- ✅ 가져온 뒤 노드 이름, 지역, 업데이트 시간이 정상적으로 표시되는지 확인합니다.
- ✅ 업데이트에 실패하면 클라이언트 안내를 기록해 네트워크 요청 실패와 형식 파싱 실패를 구분합니다.
- ✅ 연결이 완료되면 웹페이지 접속, DNS 경로, 트래픽 분할 결과를 각각 확인합니다.
- ❌ 구독 주소를 공개 검사 사이트, 포럼 본문, 공유 스크린샷에 붙여 넣지 않습니다.
- ❌ “가져오기 성공”을 곧바로 “회선 사용 가능”으로 간주하지 않습니다.
구독 업데이트가 모든 로컬 설정을 강제로 교체한다는 뜻은 아닙니다. 일부 클라이언트는 수동 규칙, 프록시 그룹 선택, 앱 권한을 유지하고, 일부는 원격 설정에 따라 일부 항목을 다시 구성합니다. 업데이트 전에 복잡한 조정을 해 두었다면 클라이언트가 로컬 덮어쓰기, 설정 백업, 규칙 병합을 지원하는지 먼저 확인해야 합니다. 구체적인 동작은 클라이언트 구현에 따라 다르므로 모든 플랫폼에 동일하게 적용할 수 없습니다.
노드, 진입점, 출구 및 회선 유형
“노드”는 일반적으로 클라이언트 목록에서 선택할 수 있는 설정을 뜻하지만, 반드시 독립된 물리 서버 한 대를 의미하지는 않습니다. 하나의 이름이 접속 진입점, 부하 분산 후의 서비스 클러스터, 중계를 거쳐 특정 출구에 도달하는 논리 회선을 나타낼 수 있습니다. 사용자가 보는 지역 태그는 보통 접속 위치나 출구 위치를 설명하지만, 정확한 의미는 서비스 제공자의 회선 안내를 기준으로 확인해야 합니다.
진입점은 클라이언트가 처음 연결을 맺는 위치이고, 출구는 대상 웹사이트가 요청이 떠난 것으로 인식하는 네트워크 위치입니다. 직결 회선은 일반적으로 클라이언트가 서비스 진입점에 직접 연결된다는 뜻이며, 그 사이에는 인터넷 사업자의 일반 네트워크가 포함될 수 있습니다. 양쪽 사이에 라우팅 노드가 없다는 의미는 아닙니다. 중계 회선은 먼저 중계 진입점에 연결한 다음 중계 네트워크를 통해 출구로 전달하며, 네트워크 간 경로 또는 연결 안정성을 조정하는 데 사용됩니다.
IEPL, 전용 회선, 중계와 직결의 차이
IEPL은 국제 이더넷 전용 회선과 관련된 상용 통신 상품명으로, 기업 간 국제 네트워크 연결에서 자주 사용됩니다. 구독 서비스가 회선 자원이나 전송 경로의 일부를 설명하기 위해 “IEPL”이라는 표현을 쓰기도 하지만, 태그만으로 전체 토폴로지, 자원 전용 여부, 혼잡 상태를 판단할 수는 없습니다. 또한 IEPL은 암호화 프로토콜이 아니므로 클라이언트와 서버 간 인증 및 암호화 설계를 대신할 수 없습니다.
전용 회선이라고 해서 언제나 더 빠르다고 이해해서는 안 됩니다. 접속 환경은 로컬 접속, 진입점 부하, 출구 네트워크, 대상 서비스, 라우팅 변화의 영향을 받습니다. 중계도 직결보다 본질적으로 우수하지 않습니다. 로컬에서 직결 진입점까지의 경로가 적합하면 추가 중계가 필요하지 않을 수 있고, 네트워크 간 경로가 불안정하면 중계가 더 적합한 경로를 제공할 수 있습니다. 실제 선택은 같은 기기와 같은 접속 대상, 비슷한 시간대에 직접 비교해 확인해야 합니다.
| 유형 | 일반적인 의미 | 확인하기 좋은 현상 | 직접 도출할 수 없는 결론 |
|---|---|---|---|
| 직결 | 클라이언트가 서비스 진입점에 직접 연결 | 핸드셰이크 성공 여부와 라우팅 안정성 | 물리 경로가 가장 짧거나 항상 지연 시간이 낮음 |
| 중계 | 먼저 중계 진입점에 연결한 뒤 출구로 전달 | 네트워크 간 경로와 혼잡 시간대의 변동 | 어떤 네트워크 환경에서도 직결보다 우수함 |
| IEPL 태그 | 일반적으로 관련 기업 전용 회선 자원을 사용한다는 의미 | 서비스 제공자가 안내하는 진입점, 출구 및 사용 환경 | 특정 프로토콜과 동일하거나 속도가 보장됨 |
주요 프로토콜은 각각 어떤 문제를 해결할까
프로토콜은 클라이언트와 서버가 데이터를 인증하고 캡슐화하며 전송하는 방식을 정합니다. 노드 지역이 같아도 프로토콜이 같다는 뜻은 아니며, 프로토콜 이름이 같아도 매개변수, 전송 계층, 클라이언트 구현이 완전히 동일하다고 볼 수 없습니다. 프로토콜을 선택하기 전에 서버가 해당 설정을 제공하는지 확인하고, 클라이언트가 동일한 프로토콜과 매개변수 조합을 지원하는지 확인해야 합니다.
Shadowsocks
Shadowsocks는 암호화 프록시 프로토콜 체계로, 지원되는 네트워크 트래픽을 원격 서버로 전달하는 데 자주 사용됩니다. 전 시스템 트래픽을 가로채는 전통적인 의미의 VPN과는 다릅니다. 모든 앱이 적용 대상인지 여부는 클라이언트가 시스템 프록시, 가상 네트워크 인터페이스, 앱 내 프록시 중 무엇을 사용하는지와 UDP, DNS, 트래픽 분할 설정이 일치하는지에 따라 달라집니다.
VMess와 VLESS
VMess는 V2Ray 생태계에서 자주 사용되며 클라이언트와 서버 간 인증 및 전송 설정을 포함합니다. VLESS는 더 간결한 프로토콜 설계를 사용하며 TLS, Reality 또는 다른 전송 방식과 함께 구성되는 경우가 많습니다. 프로토콜 계층, 전송 계층, 보안 계층은 서로 다른 개념이므로 설정을 가져올 때 “VLESS”라는 이름만 보고 서비스 이름, 인증서 검증, 전송 방식 등의 매개변수를 무시해서는 안 됩니다.
Trojan
Trojan은 일반적으로 TLS 연결을 기반으로 프록시 트래픽을 전달하며, 설정에는 서버 이름, 인증서 검증, 비밀번호 인증이 자주 포함됩니다. TLS 연결이 정상적으로 수립되는지는 도메인, 인증서, 기기 시간, 클라이언트 구현의 영향을 받습니다. 인증서 검증을 끄면 설정 오류가 가려질 수 있으므로 일반적인 문제 해결 방법으로 사용해서는 안 됩니다.
Hysteria2와 TUIC
Hysteria2와 TUIC는 모두 QUIC 기반 전송 기능을 활용하는 경우가 많으며, 지연 시간이 높거나 패킷 손실 및 네트워크 변동이 있는 환경을 고려해 설계되었습니다. 일반적으로 UDP 연결 가능 여부에 의존하므로 로컬 네트워크가 UDP를 제한하면 핸드셰이크 실패나 성능 저하가 발생할 수 있습니다. 변동성에 대응한 프로토콜 설계가 물리적 거리, 대역폭 상한, 대상 서비스의 제한을 없애 주는 것은 아닙니다.
프로토콜은 단순히 “신형인지 구형인지”만으로 선택하지 않는 것이 좋습니다. 로컬 네트워크에서 해당 전송을 허용하는지, 클라이언트가 유지 관리되는지, 시스템 권한, 연결 로그, 접속 대상 등을 함께 고려하는 편이 더 정확합니다. 서비스 패널에서 권장 설정을 제공한다면 먼저 기본값으로 기초 연결을 확인한 뒤 프로토콜이나 전송 매개변수를 조정해야 여러 변수가 동시에 바뀌어 잘못 판단하는 일을 줄일 수 있습니다.
트래픽 분할 규칙, 전체 모드와 규칙 모드
트래픽 분할은 요청이 전송되기 전에 적용됩니다. 클라이언트는 도메인, 대상 주소, 앱 출처 또는 규칙 세트를 읽은 뒤 요청에 프록시, 직결, 차단 등의 동작을 선택합니다. 규칙 모드의 목적은 회선을 자동으로 빠르게 만드는 것이 아니라 서로 다른 접속 대상을 적합한 경로로 보내고, 로컬 서비스, LAN 기기, 중계가 필요 없는 리소스가 원격 경로를 우회하지 않도록 하는 데 있습니다.
전체 모드는 일반적으로 클라이언트가 인계받은 트래픽을 가능한 한 프록시 경로로 보내는 것을 의미하지만, 실제 인계 범위는 플랫폼과 클라이언트에 따라 다릅니다. 일부 구현은 시스템 프록시를 따르는 앱에만 영향을 주고, 일부는 가상 네트워크 인터페이스를 통해 더 많은 트래픽을 처리하며, 일부는 LAN, 시스템 서비스 또는 특정 프로토콜을 예외로 남겨 둡니다. 따라서 전체 모드를 모든 데이터가 반드시 같은 노드를 거친다는 뜻으로 이해해서는 안 됩니다.
규칙 모드는 규칙 순서에 따라 매칭합니다. 도메인 규칙은 사이트 이름을 기준으로 분류할 때 적합하고, 주소 규칙은 이미 확인된 대상 주소를 처리하며, 앱 규칙은 요청을 시작한 소프트웨어에 따라 경로를 결정합니다. 상위 규칙이 지나치게 포괄적이면 뒤의 세부 규칙이 영원히 적용되지 않을 수 있습니다. DNS 조회와 트래픽 분할 판단이 서로 다른 경로를 사용하면 도메인 규칙은 올바르게 보이지만 실제 연결은 잘못된 출구로 나갈 수도 있습니다.
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-SUFFIX,intranet.example,DIRECT
MATCH,PROXY위 내용은 매칭 순서를 이해하기 위한 예시일 뿐, 모든 클라이언트에 바로 가져올 수 있는 범용 설정이 아닙니다. 클라이언트마다 동작 이름, 규칙 문법, 우선순위가 다를 수 있습니다. 수정하기 전에 클라이언트 문서를 확인하고 복구 가능한 원본 설정을 보관해야 합니다.
- ✅ 먼저 클라이언트가 실제로 전체 모드인지 규칙 모드인지 확인합니다.
- ✅ 연결 기록에서 대상 도메인이 프록시, 직결, 차단 중 어느 규칙에 매칭되었는지 확인합니다.
- ✅ LAN과 로컬 서비스가 직결 상태를 유지해야 하는지 점검합니다.
- ✅ 규칙을 업데이트한 뒤 새로 연결해 이전 연결 결과를 새 규칙의 효과로 착각하지 않도록 합니다.
- ❌ 노드 전환과 규칙 전환을 동시에 진행하지 않습니다. 어떤 변경이 적용되었는지 판단하기 어려워집니다.
- ❌ 출처가 불분명한 대규모 규칙 세트를 그대로 복사해 기존 설정을 덮어쓰지 않습니다.
DNS 누출과 “연결됐지만 열리지 않음”
DNS 누출은 일반적으로 도메인 조회가 예상한 해석 경로를 따라 전송되지 않아 로컬 네트워크 리졸버나 다른 비예상 리졸버가 조회 내용을 볼 수 있는 상태를 뜻합니다. 이는 데이터 트래픽이 노드를 거치는지와 관련은 있지만 별개의 문제입니다. 웹페이지 연결은 프록시를 거치면서 도메인 조회는 로컬 네트워크에서 처리될 수 있고, 반대로 DNS는 원격에서 처리되지만 최종 연결은 트래픽 분할 규칙에 따라 직결될 수도 있습니다.
암호화 DNS만 켠다고 해서 조회가 반드시 프록시 출구와 같은 경로를 사용하는 것은 아닙니다. 암호화 DNS는 주로 조회 전송 과정을 보호하며, 누가 조회를 수행하고 어느 네트워크 출구에서 요청을 보내는지는 시스템, 브라우저, 클라이언트 설정에 따라 달라집니다. 일부 브라우저에는 시스템 조회 경로를 우회할 수 있는 독립적인 보안 DNS 기능이 있고, 일부 클라이언트는 DNS를 인계받아 트래픽 분할 규칙에 따라 로컬 또는 원격 조회를 선택합니다.
DNS 결과는 규칙 판단에도 영향을 줄 수 있습니다. 일부 대상 서비스는 조회 출처에 따라 다른 주소를 반환할 수 있으며, 캐시에 남은 이전 결과가 계속 사용될 수도 있습니다. 문제를 확인할 때는 먼저 클라이언트가 DNS를 인계받는지 확인하고, 브라우저에 별도 조회 설정이 있는지 점검한 다음 필요한 캐시를 정리하고 다시 연결해야 합니다. 검사 페이지 하나만으로 결론을 내리지 마세요. 검사 페이지는 자신이 발생시킨 조회와 당시 출구만 볼 수 있습니다.
“주소에는 접속되지만 도메인에는 접속되지 않음”은 DNS 문제일 가능성이 높습니다. “도메인은 조회되지만 연결 시간이 초과됨”은 라우팅, 프로토콜, 포트 또는 대상 서비스와 관련될 수 있습니다. “특정 앱만 이상함”이라면 해당 앱이 시스템 프록시를 따르는지, 별도 DNS를 사용하는지, 시스템이 클라이언트에 필요한 네트워크 권한을 부여했는지 추가로 확인해야 합니다.
Windows, Android, iOS, macOS 및 Linux 클라이언트 차이
플랫폼마다 시스템 프록시, 가상 네트워크 인터페이스, 백그라운드 실행, 인증서 저장소를 관리하는 방식이 다르므로 같은 구독도 클라이언트에 따라 동작이 완전히 같지 않을 수 있습니다. VPNKX는 Windows, Android, iOS, macOS 및 Linux를 지원하며, 구체적인 클라이언트 다운로드 경로와 유효한 요금제에 따른 다운로드 권한은 계정 패널에서 확인합니다.
| 플랫폼 | 일반적인 인계 방식 | 우선 확인할 사항 |
|---|---|---|
| Windows | 시스템 프록시 또는 가상 네트워크 인터페이스 | 프록시 잔여 설정, 네트워크 인터페이스, 시스템 방화벽, 앱의 프록시 준수 여부 |
| Android | 시스템 VPN 인터페이스 또는 앱 프록시 | VPN 권한, 백그라운드 제한, 앱별 트래픽 분할 및 배터리 정책 |
| iOS | 시스템 네트워크 확장 및 VPN 설정 | 설정 승인, 주문형 연결, 시스템 네트워크 전환 및 클라이언트 상태 |
| macOS | 시스템 프록시, 네트워크 확장 또는 가상 인터페이스 | 네트워크 확장 승인, 시스템 프록시 잔여 설정 및 DNS 구성 |
| Linux | 환경 프록시, 데스크톱 프록시 또는 가상 인터페이스 | 시작 권한, 라우팅 테이블, DNS 관리 서비스 및 터미널 환경 변수 |
데스크톱 플랫폼의 브라우저, 터미널, 독립 앱은 서로 다른 프록시 설정을 읽을 수 있습니다. 예를 들어 브라우저는 접속되지만 터미널 명령이 실패한다고 해서 반드시 노드 문제인 것은 아닙니다. 터미널이 프록시 환경을 상속하지 않았을 수도 있습니다. 모바일 플랫폼에서는 시스템 권한, 백그라운드 제한, 네트워크 전환 후 터널이 제대로 복구되지 않는 문제가 더 흔합니다. Linux는 배포판과 데스크톱 환경의 차이가 크므로 가져오기에 성공한 뒤 라우팅 테이블과 DNS 관리 구성 요소가 예상대로 업데이트되었는지도 확인해야 합니다.
플랫폼을 옮길 때 모든 고급 매개변수를 수동으로 그대로 복사하는 것은 권장하지 않습니다. 계정 패널에서 해당 플랫폼의 진입점을 확인하고 새 클라이언트에서 구독을 다시 가져온 다음, 꼭 필요한 트래픽 분할 설정만 하나씩 복원하는 편이 안전합니다. 원인을 확인하기 어려운 오류가 발생하면 클라이언트 로그와 문제 해결 안내서를 함께 참고하세요.
초보자를 위한 첫 검증 절차
처음 사용할 때의 목표는 복잡한 규칙을 곧바로 구성하는 것이 아니라 반복해서 확인할 수 있는 기본 경로를 만드는 것입니다. 먼저 로컬 네트워크가 정상인지 확인하고, 계정 패널에 로그인해 클라이언트와 구독을 가져옵니다. 가져온 뒤에는 기본 설정을 사용하고 접속 대상에 맞는 지역을 선택해 클라이언트가 핸드셰이크를 완료하는지 확인합니다. 이후 웹페이지, DNS, 사용할 앱을 각각 검증합니다.
- ✅ 클라이언트를 켜지 않은 상태에서도 로컬 네트워크로 자주 사용하는 서비스에 정상적으로 접속되는지 확인합니다.
- ✅ 사용자 이름과 비밀번호로 VPNKX 계정을 만들거나 로그인합니다. 이메일 주소는 필요하지 않습니다.
- ✅ 패널에서 해당 플랫폼용 클라이언트와 구독을 받고, 출처가 불분명한 설정은 사용하지 않습니다.
- ✅ 가져온 뒤 먼저 기본 프로토콜, DNS, 트래픽 분할 설정을 유지한 채 기본 연결을 확인합니다.
- ✅ 접속 대상에 맞는 지역을 선택하고 실제 출구가 예상과 일치하는지 확인합니다.
- ✅ 그다음 사용할 브라우저나 앱을 테스트하고 문제가 어느 단계에서 발생했는지 기록합니다.
- ❌ 기본 연결을 확인하기 전에 프로토콜, 노드, DNS, 규칙 세트를 동시에 변경하지 않습니다.
기본 설정이 정상적으로 작동한다면 사용 환경에 맞게 트래픽 분할 규칙을 조정하거나 회선을 비교해 보세요. 변경 후 문제가 생기면 이전의 정상 설정으로 돌아가 한 번에 하나의 변수만 바꿉니다. 모든 옵션을 자주 전환하는 것보다 신중한 방법이지만, 실제 원인을 찾기에는 더 효과적입니다.
VPNKX는 110+개 국가와 160+개 회선을 아우르는 지역 선택을 제공하며, 계정은 대수 제한 없이 기기에서 사용할 수 있습니다. 지역 수는 선택 범위를 넓히기 위한 기준일 뿐, 모든 로컬 네트워크와 대상 서비스에서 각 회선이 동일한 결과를 보장한다는 뜻은 아닙니다. 회선 정보는 선택을 위한 참고 자료이며, 실제 접속은 현재 네트워크에서 직접 확인해야 합니다.
이 용어들을 이해하면 자주 발생하는 문제를 더 구체적인 점검 과제로 바꿀 수 있습니다. 구독 문제는 설정 배포, 노드 문제는 접속과 출구, 프로토콜 문제는 호환성과 매개변수, 트래픽 분할 문제는 규칙 매칭, DNS 문제는 조회 경로, 플랫폼 문제는 시스템 인계 방식을 확인하면 됩니다. 계정 이용, 클라이언트 설치, 기본 연결 순서를 알아보려면 빠른 시작을 계속 확인하세요.