VPN 추천 초보자 용어 정리: 구독, 노드, 프로토콜, 트래픽 분할 한눈에 이해하기

VPN 초보자가 가장 자주 막히는 부분은 설치보다 ‘구독, 노드, 프로토콜, 트래픽 분할’의 관계를 이해하는 일입니다. 각각 설정을 불러오는 입구, 선택 가능한 출구, 데이터 전송 방식, 트래픽 처리 결정을 뜻합니다. 이 흐름을 정리하면 클라이언트 가져오기, 지역 전환, 웹페이지 접속 장애 점검도 더 이상 막막하지 않습니다.

먼저 간단한 구조를 기억해 두세요. 서비스 제공자가 구독을 제공하고, 구독에는 노드 설정이 포함됩니다. 클라이언트는 설정을 읽어 프로토콜에 따라 연결을 만들고, 트래픽 분할 규칙은 어떤 요청을 그 연결로 보낼지 결정합니다. 노드에 표시된 국가나 지역은 출구 위치이며, 회선 유형은 로컬 네트워크에서 출구까지 데이터가 대략 어떤 경로로 이동하는지를 설명합니다. 각 용어는 서로 다른 계층에 있으므로 서로 바꿔 쓸 수 없습니다.

구독, 구독 링크, 설정 파일이란?

구독은 특정 클라이언트도, 고정된 하나의 회선도 아닙니다. 서버에서 관리하는 설정 목록에 가깝고, 여기에는 노드 이름, 서버 주소, 포트, 프로토콜 유형, 인증 정보 및 기타 연결 매개변수가 포함될 수 있습니다. 클라이언트가 이 목록을 읽어야 선택 가능한 노드 목록이 만들어집니다.

구독 링크는 이 목록을 가져오는 주소입니다. 호환되는 클라이언트에 링크를 가져오면 클라이언트가 보통 설정을 다운로드하고 해석합니다. 서버에서 회선을 조정할 때는 구독을 업데이트해 변경 사항을 클라이언트에 동기화할 수 있으므로 항목을 하나씩 직접 입력할 필요가 없습니다. 구독 링크에는 대개 전용 접근 인증 정보가 포함되므로 비밀번호처럼 보관하고, 공개 게시물·스크린샷·온라인 변환 사이트에 올리지 마세요.

설정 파일은 로컬에 저장되는 정적인 내용입니다. 구독에서 내보낼 수도 있고 사용자가 직접 작성할 수도 있습니다. 정적 파일은 서버 변경 사항을 자동으로 따라가지 않으므로 회선 주소가 바뀌면 다시 다운로드하거나 직접 수정해야 합니다. 초보자라면 개별 노드 매개변수를 복사하는 것보다 구독을 바로 가져오는 편이 간편하지만, 문제가 생겼을 때 설정의 출처는 확인할 수 있어야 합니다.

구독 서비스
  └─ 구독 링크 또는 설정 파일
      └─ 여러 노드 설정
          └─ 클라이언트에서 노드 선택
              └─ 프로토콜로 연결 설정
                  └─ 트래픽 분할 규칙으로 요청 처리

가져오기와 업데이트는 다릅니다

가져오기는 구독을 클라이언트에 추가하는 작업이고, 업데이트는 구독 주소에 다시 요청해 최신 내용을 받는 작업입니다. 처음 가져오기에 성공한 뒤에도 클라이언트의 노드 목록은 당시 내려받은 복사본일 뿐입니다. 노드 이름이 바뀌었거나 기존 회선이 작동하지 않거나 새 지역이 표시되지 않는다면 클라이언트를 반복해서 재설치하기보다 먼저 구독을 업데이트하세요.

✅ 사용자 패널에서 구독 링크 전체를 복사해 끝부분의 매개변수가 빠지지 않게 하세요.
✅ 클라이언트에서 ‘링크에서 가져오기’ 또는 같은 의미의 메뉴를 선택하세요.
✅ 가져온 뒤 구독을 직접 업데이트해 노드 목록이 정상적으로 새로 고쳐지는지 확인하세요.
✅ 노드를 하나 선택한 다음 시스템 프록시, 터널 또는 클라이언트 연결을 켜세요.
❌ 출처가 불분명한 온라인 변환 도구에 구독 링크를 입력하지 마세요.
❌ ‘가져오기 성공’을 대상 애플리케이션도 이미 프록시를 사용한다는 뜻으로 오해하지 마세요.

결론 구독은 설정을 전달하고 클라이언트는 설정을 읽습니다. 클라이언트는 바꿀 수 있지만 구독은 기존 서비스에서 계속 관리하며, 클라이언트를 삭제해도 서버의 구독 내용이 자동으로 변경되지는 않습니다.

노드, 서버, 출구, 회선은 어떻게 다를까?

노드는 클라이언트에서 선택할 수 있는 연결 설정입니다. 보통 특정 서버 진입점을 가리키지만 노드 이름이 전용 서버 한 대를 의미하는 것은 아닙니다. 서버는 로드 밸런싱, 진입점 전달 또는 여러 출구 리소스를 통해 연결을 구성할 수 있으므로 표시 이름만으로 하위 장비 구조를 추정하지 마세요.

서버는 실제로 네트워크 연결을 처리하는 호스트 또는 서비스 인스턴스입니다. 클라이언트의 노드가 출구 서버에 직접 연결될 수도 있고, 먼저 진입점에 연결한 뒤 중계 과정을 거쳐 출구에 도달할 수도 있습니다. 일반 사용자에게 더 중요한 것은 출구 지역, 회선 유형, 프로토콜 호환성, 실제 안정성이지 서버 하드웨어를 추측하는 일이 아닙니다.

출구는 요청이 프록시 네트워크를 빠져나가는 위치로, 대상 웹사이트가 확인하는 지점입니다. 일본 노드를 선택하고 회선이 정상적으로 작동한다면 웹사이트는 대개 일본 출구 주소에서 접속한 것으로 인식합니다. 노드 이름에 특정 지역이 적혀 있어도 실제 점검을 대신할 수는 없습니다. 연결 후에는 사이트의 IP 확인으로 출구 지역을 확인하세요.

회선은 데이터가 이동하는 경로를 설명합니다. 노드는 클라이언트에서 클릭하는 항목에 가깝고, 회선은 로컬 네트워크에서 진입점과 중간 네트워크를 거쳐 출구에 이르는 과정을 강조합니다. 같은 출구 지역에도 직접 연결, 중계, 전용 회선 등 여러 경로가 있을 수 있으며, 저녁 시간 혼잡도·망 간 연결 성능·장애 전환 방식이 서로 다를 수 있습니다.

용어	답하는 질문	초보자가 흔히 하는 오해	올바른 확인 방법
구독	설정은 어디에서 가져오는가	구독을 클라이언트 프로그램으로 생각함	구독을 가져오고 업데이트할 수 있는지 확인
노드	현재 어떤 연결 설정을 선택했는가	하나의 이름이 반드시 전용 장비 한 대를 뜻한다고 생각함	전환 후 연결과 출구를 확인
프로토콜	클라이언트와 서버는 어떻게 통신하는가	프로토콜 이름이 곧 회선 품질을 뜻한다고 생각함	양쪽의 호환성을 확인하고 실제로 연결
회선	데이터가 대략 어떤 경로를 지나는가	출구 지역만 보고 중간 경로는 확인하지 않음	시간대와 로컬 네트워크를 달리해 테스트
트래픽 분할	어떤 요청을 프록시로 보낼 것인가	노드를 선택하면 모든 애플리케이션이 그 노드를 거친다고 생각함	모드, 규칙 적용 여부, 시스템 프록시를 확인

직접 연결, 중계, IEPL 전용 회선

직접 연결 회선은 로컬 네트워크에서 원격 서비스 진입점으로 바로 접속하며, 서비스 제공자가 별도로 마련한 전달 진입점을 거치지 않는 방식입니다. 구조는 단순하지만 실제 사용 경험은 로컬 통신사와 원격 네트워크 사이의 라우팅에 크게 좌우됩니다. 거리가 가깝다고 경로가 반드시 좋은 것은 아니며, 지도상의 직선거리도 데이터가 거치는 자율 시스템과 교환 노드를 보여주지 않습니다.

중계 회선은 먼저 접근하기 쉬운 진입점에 연결한 뒤 진입점이 대상 출구로 전달하는 방식입니다. 중계의 목적은 대개 품질이 낮은 공용 네트워크 경로를 피하고 망 간 연결이나 혼잡 시간대의 성능을 개선하는 데 있습니다. 다만 진입점 품질, 중계 경로, 출구 부하, 로컬 네트워크가 모두 결과에 영향을 주므로 자동으로 더 빠르다는 뜻은 아닙니다.

IEPL 전용 회선은 일반적으로 통신사의 국제 이더넷 전용 회선 자원으로 핵심 구간을 운반하고, 진입점과 출구를 조합해 서비스를 제공하는 방식을 뜻합니다. 일반 공용 네트워크 직접 연결과 경로 구성 방식이 다르며, 회선 안정성이 중요한 상황에서 사용됩니다. 그러나 ‘전용 회선’이라는 표기가 테스트를 대신해 주는 것은 아닙니다. 클라이언트 프로토콜, 진입점 접속 품질, 사용 중인 네트워크가 최종 성능에 영향을 줍니다.

선택 방법 먼저 거리와 대상 서비스 지역에 적합한 출구를 고른 뒤 직접 연결·중계·전용 회선의 실제 성능을 비교하세요. 노드 이름에 있는 ‘고속’, ‘프리미엄’ 같은 표현만으로 결정하면 참고 가치가 제한적입니다.

프로토콜 용어는 무엇을 뜻할까?

프로토콜은 클라이언트와 서버가 데이터를 캡슐화하고 인증하며 전송하는 방식을 정의합니다. 즉 ‘어떻게 연결하는가’를 해결하는 요소이지 ‘물리적 회선이 어떤 경로로 이동하는가’를 정하는 요소는 아닙니다. 같은 네트워크 경로에서 서로 다른 프로토콜을 사용할 수 있고, 같은 프로토콜도 품질이 크게 다른 회선에 배치될 수 있습니다. 따라서 최신 프로토콜이라고 노드가 반드시 빠른 것은 아니며, 노드가 느리다고 곧바로 프로토콜 탓이라고 할 수도 없습니다.

Shadowsocks

Shadowsocks는 널리 사용되는 암호화 프록시 프로토콜로, 설정에는 보통 서버 주소·포트·암호화 방식·비밀번호가 포함됩니다. 클라이언트 생태계가 넓고 구조도 비교적 단순합니다. 다만 구현마다 지원하는 암호화 방식이 다를 수 있습니다. 가져온 뒤 ‘지원하지 않는 암호화 방식’이라는 메시지가 표시되면 설정 필드를 임의로 바꾸기보다 클라이언트를 업데이트하거나 서비스 제공자가 권장하는 호환 클라이언트를 사용하세요.

VMess와 VLESS

VMess와 VLESS는 Xray, V2Ray 관련 생태계에서 자주 사용됩니다. VMess 자체에는 인증과 프로토콜 구조가 포함되고, VLESS는 더 가벼운 인증 방식에 가깝습니다. 보통 TLS, Reality, WebSocket, gRPC 같은 전송 또는 보안 계층과 함께 사용합니다. 클라이언트에 VLESS라고 표시된다고 해서 모든 VLESS 노드의 매개변수를 서로 바꿔 쓸 수 있는 것은 아닙니다. 전송 방식, 서버 이름, 경로, 공개 키 등의 필드는 서버 설정과 일치해야 합니다.

Trojan

Trojan은 보통 TLS 위에서 실행되며, 설정에서 중요한 항목은 서버 주소, 인증 정보, 서버 이름, 인증서 검증 관련 매개변수입니다. 인증서 검증에 실패했다고 ‘검증 건너뛰기’를 기본 해결책으로 사용해서는 안 됩니다. 시스템 시간, 서버 이름, 구독 만료 여부, 클라이언트가 설정을 올바르게 읽었는지부터 확인하는 편이 안전합니다.

Hysteria2와 TUIC

Hysteria2와 TUIC는 모두 QUIC 기반 전송 방식을 사용하며, 지연 시간이 높거나 어느 정도 패킷 손실이 있는 환경에서 전송 성능을 개선하고자 할 때 활용됩니다. 두 프로토콜 모두 UDP 사용 가능 여부에 영향을 받습니다. 회사 네트워크, 공용 네트워크 또는 라우터 장비가 UDP를 제한하면 핸드셰이크 실패, 불안정한 연결, 완전한 접속 불가가 발생할 수 있습니다. 이때는 관련 없는 매개변수를 계속 수정하기보다 현재 네트워크에서 사용할 수 있는 다른 프로토콜로 전환하는 편이 효과적입니다.

초보자가 프로토콜을 선택할 때는 클라이언트가 기본적으로 지원하는지, 현재 네트워크가 해당 전송 방식을 허용하는지, 서버가 완전한 설정을 제공하는지를 우선 고려하세요. 구독에 이미 사용할 수 있는 노드가 포함되어 있다면 보통 직접 프로토콜을 바꿀 필요가 없습니다. 수동 수정은 서버 매개변수와 각 필드의 의미를 정확히 알고 있을 때만 적합합니다.

시스템 프록시, 가상 네트워크 어댑터, 터널 모드

클라이언트가 노드에 성공적으로 연결된 뒤에도 애플리케이션의 트래픽이 클라이언트로 들어오도록 해야 합니다. 일반적인 방식으로는 시스템 프록시와 가상 네트워크 어댑터 기반의 터널 모드가 있습니다. 두 방식은 단순한 상하 관계가 아니라 트래픽을 가로채는 범위와 구현 방식이 서로 다릅니다.

시스템 프록시는 운영체제의 프록시 설정을 변경합니다. 시스템 프록시를 따르는 브라우저와 애플리케이션은 요청을 로컬 프록시 포트로 보내지만, 일부 게임·명령줄 도구·독립 업데이트 프로그램·자체 네트워크 스택을 사용하는 애플리케이션은 이 설정을 무시할 수 있습니다. ‘브라우저는 되는데 터미널은 안 된다’면 먼저 대상 프로그램이 시스템 프록시를 읽는지 확인하세요.

가상 네트워크 어댑터 또는 터널 모드는 가상 네트워크 인터페이스를 만들고 라우팅 규칙으로 더 넓은 범위의 트래픽을 처리합니다. 시스템 프록시를 지원하지 않는 애플리케이션까지 포함할 수 있지만, 기업용 VPN·가상 머신 네트워크·컨테이너 네트워크·보안 프로그램·다른 네트워크 필터와 충돌하기도 쉽습니다. 활성화 후 로컬 서비스에 접근할 수 없다면 노드만 바꾸지 말고 라우팅과 우회 규칙을 확인하세요.

명령줄 도구는 환경 변수를 읽을 수도 있습니다. 그래픽 클라이언트에서 시스템 프록시를 켰다고 해서 모든 터미널 프로세스가 자동으로 이를 상속하는 것은 아닙니다. 도구마다 지원하는 변수와 프록시 유형이 다르므로 해당 도구의 문서를 확인하고, 사용이 끝나면 임시 설정을 삭제하세요.

브라우저 요청
  ├─ 시스템 프록시 사용 → 로컬 클라이언트 → 원격 노드
  └─ 시스템 프록시 무시 → 로컬 네트워크로 직접 연결

터널 모드 요청
  └─ 라우팅이 가상 네트워크 어댑터로 진입 → 트래픽 분할 규칙 → 프록시 또는 직접 연결

전역·규칙·직접 연결 모드는 어떻게 선택할까?

전역 모드는 일반적으로 클라이언트가 처리하는 트래픽을 현재 프록시 노드를 통해 최대한 전송하는 방식입니다. 문제를 임시로 진단할 때 유용합니다. 규칙 모드에서 대상 서비스가 열리지 않지만 전역 모드에서는 열릴 경우, 문제는 노드 자체의 사용 불가보다 규칙 매칭·DNS 정책·애플리케이션 미처리일 가능성이 큽니다.

규칙 모드는 도메인, IP, 프로세스, 지역 데이터베이스 또는 사용자 지정 조건에 따라 프록시·직접 연결·차단 중 하나를 결정합니다. 로컬 웹사이트, 로컬 네트워크, 국제 회선이 필요하지 않은 요청을 직접 연결로 유지할 수 있어 일상적인 사용에 적합합니다. 다만 규칙을 지속적으로 관리해야 하며, 도메인 변경·공유 인프라·애플리케이션 내부 요청 때문에 잘못 판단할 수 있습니다.

직접 연결 모드는 요청이 원격 노드를 거치지 않는 방식입니다. 프록시를 잠시 중지하거나 로컬 네트워크 장비에 접근하거나 문제가 프록시 경로에서 비롯됐는지 확인할 때 사용할 수 있습니다. 직접 연결이라고 해서 클라이언트가 종료되는 것은 아닙니다. 일부 클라이언트는 로컬 DNS, 규칙 엔진 또는 가상 네트워크 어댑터를 계속 실행할 수 있으므로 네트워크를 완전히 복구하려면 클라이언트 안내에 따라 관련 기능을 끄세요.

먼저 규칙 모드에서 노드에 연결한 뒤 대상 서비스를 엽니다.
실패하면 전역 모드로 잠시 전환해 다시 테스트합니다.
전역 모드는 작동하지만 규칙 모드가 작동하지 않는다면 도메인이 잘못된 규칙에 매칭되는지 확인합니다.
전역 모드에서도 작동하지 않으면 구독 업데이트, 프로토콜 호환성, 노드 상태를 차례로 확인합니다.
직접 연결 모드로 돌아가 로컬 네트워크 자체가 정상인지 확인합니다.

일상적인 권장 방식 규칙 모드는 장기 사용에, 전역 모드는 트래픽 분할 문제를 빠르게 찾는 데, 직접 연결 모드는 비교 기준을 마련하는 데 활용하세요. 장애가 발생했을 때 이 순서로 비교하면 노드를 무작정 계속 바꾸는 것보다 원인을 쉽게 찾을 수 있습니다.

DNS, DNS 누출, 출구 확인

DNS는 도메인 이름을 연결 가능한 주소로 변환합니다. 프록시 연결이 정상이라고 해서 DNS도 반드시 같은 경로를 사용하는 것은 아닙니다. 클라이언트는 시스템 DNS, 원격 DNS, 암호화 DNS 또는 내장 리졸버를 사용할 수 있으며, 규칙 모드는 해석 결과에 따라 트래픽 방향을 다시 결정하기도 합니다. DNS 설정과 트래픽 분할 규칙은 서로 영향을 주므로 ‘노드는 연결됐는데 웹사이트가 열리지 않는’ 흔한 원인 중 하나입니다.

DNS 누출은 일반적으로 프록시 측에서 처리되어야 하는 도메인 조회가 실제로는 로컬 네트워크의 DNS 서비스로 전송되는 현상을 뜻합니다. 로컬 네트워크가 사용하는 DNS 제공자가 노출될 수 있고 지역별 해석 결과가 달라질 수도 있습니다. 예를 들어 웹 연결은 원격 출구를 사용하지만 도메인 해석은 로컬 네트워크에 적합한 주소를 반환하면 콘텐츠 지역이 일치하지 않거나 연결 경로가 우회될 수 있습니다.

점검할 때 IP 주소만 확인하지 마세요. 출구 지역, DNS 해석 위치, 브라우저의 별도 보안 DNS 사용 여부, IPv6 직접 연결 여부를 함께 확인해야 합니다. 브라우저 자체 DNS 설정이 클라이언트의 예상 정책을 우회할 수 있으며, 운영체제와 클라이언트가 서로 다른 해석 방식을 동시에 사용하면 예측하기 어려운 결과가 생길 수 있습니다.

✅ 연결 후 공용 네트워크 출구가 선택한 지역으로 변경되었는지 먼저 확인하세요.
✅ DNS 조회가 예상한 DNS 서비스에서 처리되는지 확인하세요.
✅ 브라우저와 운영체제의 DNS 설정이 서로 충돌하지 않는지 확인하세요.
✅ 규칙 모드가 비정상일 때는 전역 모드로 비교 결과를 확인하세요.
❌ ‘웹페이지가 열린다’는 사실만으로 DNS와 트래픽 분할이 완벽하다고 판단하지 마세요.
❌ 영향을 이해하지 못한 상태에서 여러 DNS 처리 기능을 동시에 활성화하지 마세요.

플랫폼마다 클라이언트 화면이 다른 이유

Windows, macOS, Android, iOS, Linux 클라이언트는 시스템 네트워크 인터페이스, 권한 모델, 백그라운드 정책의 영향을 받으므로 메뉴 구성이 완전히 같지 않습니다. 같은 구독도 클라이언트에 따라 노드 정렬, 속도 측정 버튼, 규칙 이름, 로그 형식이 다르게 표시될 수 있지만 핵심 흐름은 설정 가져오기, 노드 선택, 연결 설정, 트래픽 분할 지정, 출구 확인으로 같습니다.

데스크톱 시스템은 보통 연결 로그, 라우팅 테이블, 로컬 수신 포트를 확인하기 편하지만 가상 머신·컨테이너·기업용 네트워크 프로그램과 충돌하기도 쉽습니다. 모바일 운영체제는 백그라운드 실행과 VPN 권한 관리가 더 엄격하므로 네트워크 전환, 절전 상태 진입, 장시간 백그라운드 실행 후 시스템이 연결을 다시 조정할 수 있습니다. 연결이 끊기면 시스템 권한과 백그라운드 정책을 함께 확인하세요.

Linux에서는 그래픽 인터페이스가 필수가 아닙니다. 많은 클라이언트가 설정 파일과 서비스 프로세스로 실행되지만 시스템 프록시 환경 변수, 데스크톱 프록시 설정, 라우팅, DNS가 서로 다른 구성 요소로 나뉠 수 있습니다. 핵심 프로세스만 실행하고 트래픽 진입점을 설정하지 않으면 애플리케이션은 자동으로 노드를 사용하지 않습니다. 명령줄에서 프로세스가 실행 중이라는 표시만으로는 핵심 기능이 시작됐다는 사실만 알 수 있으며, 트래픽 분할 경로가 완성됐다는 뜻은 아닙니다.

클라이언트 이름만으로 프로토콜 호환성이 결정되는 것도 아닙니다. 가져오기 전에 지원하는 프로토콜, 전송 계층, 구독 형식을 확인하세요. 노드가 ‘지원되지 않음’으로 표시되면 설정의 필드 의미를 모르는 상태에서 보안 매개변수를 삭제하지 말고 서비스 제공자가 제공하거나 권장하는 클라이언트 버전을 우선 사용하세요.

초보자는 어떤 순서로 문제를 점검해야 할까?

네트워크 문제는 여러 계층에서 발생하는 경우가 많습니다. 노드를 무작정 바꾸면 일시적으로 복구될 수 있지만 구독 미업데이트, 프로토콜 비호환, 트래픽 분할 누락, 로컬 네트워크 제한 중 무엇이 원인인지 알기 어렵습니다. 정해진 순서로 확인하면 원인 범위를 단계적으로 좁힐 수 있습니다.

로컬 네트워크 확인: 프록시 처리를 끈 뒤 일반 웹사이트와 DNS가 정상인지 확인합니다.
구독 업데이트: 노드 주소 변경, 오래된 설정 잔존, 구독 읽기 실패를 배제합니다.
클라이언트 로그 확인: 해석 실패, 연결 시간 초과, 인증 실패, 인증서 오류를 구분합니다.
같은 지역 노드로 전환: 문제가 특정 노드나 특정 프로토콜에 집중되는지 확인합니다.
트래픽 분할 모드 비교: 규칙 모드는 실패하고 전역 모드는 작동한다면 규칙과 DNS를 중점적으로 확인합니다.
트래픽 처리 범위 확인: 대상 애플리케이션이 시스템 프록시를 사용하는지 또는 터널 모드가 처리하는지 확인합니다.
출구 검증: 공용 주소가 대상 지역과 일치하는지 확인한 뒤 대상 서비스를 다시 엽니다.

로그의 ‘시간 초과’는 대기 시간 안에 예상한 응답을 받지 못했다는 뜻일 뿐 서버가 오프라인이라는 증거는 아닙니다. DNS, 라우팅, 방화벽, UDP 제한, 프로토콜 매개변수 불일치도 비슷한 현상을 일으킬 수 있습니다.

특정 애플리케이션만 실패하고 브라우저와 다른 도구는 정상이라면 해당 애플리케이션이 시스템 프록시를 무시하는지, 독립 DNS를 사용하는지, 특정 네트워크 프로토콜을 고정해 사용하는지, 트래픽 분할 규칙이 관련 도메인을 처리하는지부터 확인하세요. 모든 애플리케이션이 실패한다면 노드 연결, 구독, 로컬 네트워크 계층으로 돌아가 점검합니다.

이 용어들을 이해하면 하나의 연결을 다음과 같이 설명할 수 있습니다. 클라이언트가 구독에서 노드 설정을 가져오고, 지정된 프로토콜로 진입점에 연결하며, 데이터는 직접 연결·중계·전용 회선 경로를 따라 출구에 도달합니다. 트래픽 분할 규칙은 각 요청을 프록시로 보낼지 직접 연결할지 결정하고, DNS 정책은 도메인을 해석합니다. 장애 점검도 ‘연결’ 버튼의 색상만 보지 말고 이 흐름을 따라 계층별로 진행해야 합니다.