Mac VPN 추천 2026에서 실제로 비교해야 할 것은 노드 이름과 프로토콜 목록만이 아닙니다. macOS는 프록시, VPN 구성, 네트워크 확장과 백그라운드 구성 요소를 각각 관리합니다. 클라이언트가 실행된다고 해서 트래픽이 예상대로 회선으로 들어간다는 뜻은 아닙니다. 도구를 잘못 선택하면 브라우저는 접속되지만 iCloud 동기화가 느려지거나, 잠자기에서 깨어난 뒤 화면에는 연결됨으로 표시되어도 실제 출구와 DNS는 로컬 네트워크로 돌아가는 일이 흔합니다.
더 신뢰할 수 있는 선택 방법은 먼저 클라이언트가 macOS 네트워크 스택에 어떻게 연결되는지 확인한 뒤, 분할 라우팅 규칙으로 Apple 서비스가 정상 작동하는지 확인하고, 마지막으로 앱이 M 시리즈 칩에 네이티브로 맞춰졌는지 검증하는 것입니다. 프로토콜 이름도 중요하지만 전송 방식의 일부만 결정합니다. 권한 처리, 라우팅 제어, DNS 정책과 업데이트 관리가 일상적인 사용 편의성을 좌우합니다.
Mac 추천 기준: 연결 방식을 먼저 확인하세요
macOS에서 흔히 사용하는 연결 방식은 시스템 VPN 구성, 네트워크 확장, 시스템 프록시, 가상 네트워크 인터페이스 모드로 나눌 수 있습니다. 단순한 상하 관계가 아니라 트래픽을 제어하는 범위가 다릅니다. 시스템 프록시는 프록시 설정을 읽는 앱에 주로 영향을 주며, 일부 명령줄 프로그램과 독립 네트워크 구성 요소, 자체 연결 로직을 사용하는 소프트웨어는 이를 우회할 수 있습니다. 가상 네트워크 인터페이스 또는 네트워크 확장 기반 터널 모드는 전체 트래픽 제어에 더 가깝지만, 권한·라우팅·DNS 설정이 올바른지에 더 크게 의존합니다.
| 연결 방식 | 주요 특징 | 적합한 사용 환경 | 확인할 항목 |
|---|---|---|---|
| 시스템 VPN 구성 | macOS가 연결 상태를 통합 표시하고 시스템이 기본 수명 주기를 관리합니다 | 프로토콜은 시스템 또는 클라이언트 확장의 지원을 받으며 요구 사항이 비교적 고정적입니다 | 구성 출처, 주문형 연결, DNS 및 연결 해제 후 라우팅 복원 |
| 네트워크 확장 | Apple이 제공하는 네트워크 확장 메커니즘으로 터널을 만들거나 트래픽을 필터링합니다 | 앱 트래픽을 안정적으로 제어하면서 시스템 권한 체계와 함께 사용해야 할 때 적합합니다 | 권한 승인 완료 여부, 확장 활성화 여부, 잠자기에서 깨어난 뒤 복구 여부 |
| 시스템 프록시 | 설정이 간단하며 프록시 규칙에 따라 작동하는 앱에 적합합니다 | 브라우저 접속, 개발 디버깅 또는 일부 트래픽만 프록시해야 할 때 | 앱이 시스템 프록시를 따르는지, 프록시를 끈 뒤 설정이 복원되는지 |
| 가상 네트워크 인터페이스 모드 | 더 많은 네트워크 트래픽을 사용자 영역의 코어로 보내 복잡한 분할 라우팅을 실행할 수 있습니다 | 브라우저, 명령줄 도구와 여러 데스크톱 앱을 함께 사용해야 할 때 | 기본 라우팅, 로컬 네트워크 접근, DNS 제어와 비정상 종료 후 정리 |
클라이언트를 처음 실행했을 때 시스템에서 VPN 구성을 추가하거나 네트워크 확장을 활성화하도록 요구하면, 먼저 요청 주체가 현재 설치한 앱과 일치하는지 확인하세요. 권한 승인이 끝난 뒤에는 클라이언트로 돌아가 확장 상태도 확인해야 합니다. 시스템 팝업이 사라졌는지만 봐서는 안 됩니다. 일부 앱은 메인 창에 이미 회선 이름을 표시하지만 확장은 아직 활성화되지 않았을 수 있으며, 이 경우 트래픽이 계속 기존 네트워크를 사용할 수 있습니다.
클라이언트가 시스템 프록시에 전적으로 의존한다면 터미널의 네트워크 요청, 소프트웨어 업데이트 프로그램과 독립 네트워크 스택을 사용하는 앱을 추가로 테스트해야 합니다. 웹페이지가 열린다는 것은 브라우저가 현재 프록시 설정을 따른다는 뜻일 뿐, Mac 전체의 트래픽이 제어되고 있다는 증거는 아닙니다. 반대로 전역 터널이라고 해서 모든 트래픽이 원격으로 가야 하는 것도 아닙니다. 로컬 네트워크 기기, 프린터 서비스와 일부 Apple 서비스에는 더 세밀한 규칙이 필요한 경우가 많습니다.
- ✅ 클라이언트가 네트워크 확장, 시스템 프록시 또는 가상 네트워크 인터페이스의 현재 상태를 명확히 표시합니다
- ✅ 비정상 종료 후 시스템 프록시, 기본 라우팅과 DNS 설정을 복원합니다
- ✅ 규칙 기반 분할 라우팅을 지원하고 현재 적용된 회선 또는 정책을 확인할 수 있습니다
- ✅ 잠자기에서 깨어나거나 네트워크를 전환한 뒤 연결을 다시 검증하며 이전 아이콘만 유지하지 않습니다
- ❌ 연결됨만 표시하고 출구 주소, DNS 상태 또는 실행 로그를 확인할 수 없습니다
- ❌ 구성을 반복해서 삭제해야 로컬 네트워크를 복구할 수 있고 정리 방법도 안내하지 않습니다
네트워크 확장 권한이 안정성을 좌우하는 이유
네트워크 확장은 macOS가 터널, 프록시와 콘텐츠 필터링 기능을 관리하는 중요한 인터페이스입니다. 사용자가 구성을 허용하면 시스템은 해당 구성 요소를 권한 및 수명 주기 관리에 포함합니다. 클라이언트 업그레이드, 기기 이전 또는 백업 복원 후에는 확장 상태를 다시 확인해야 할 수 있으므로, 예전에 작동했다는 사실만으로 현재 상태를 대신할 수 없습니다.
연결 버튼을 눌러도 반응이 없을 때는 연속으로 클릭하거나 구독을 반복해서 가져오지 마세요. 먼저 시스템 설정의 VPN 및 필터 관련 페이지에서 대상 구성이 존재하는지 확인한 뒤, 클라이언트에 확장이 활성화되지 않았다는 안내가 있는지 살펴보세요. 네트워크 도구를 여러 개 설치했다면 기본 라우팅, DNS 또는 시스템 프록시를 모두 제어하려는지 확인해야 합니다. 여러 도구가 겹치면 마지막에 실행한 앱이 앞서 남은 구성을 완전히 덮어쓰지 못할 수 있습니다.
권한 승인 후에도 확인해야 할 항목
권한 승인은 시스템이 구성 요소 실행을 허용한다는 뜻일 뿐, 회선에 반드시 도달한다는 뜻은 아닙니다. 다음으로 터널이 만들어졌는지, 기본 라우팅이 전환됐는지, DNS 조회가 규칙에 따라 처리되는지 각각 확인해야 합니다. 클라이언트가 실행 로그를 제공한다면 구성 로드, 라우팅 기록, DNS 초기화와 핸드셰이크 결과를 확인할 수 있지만, 정상적인 재시도 메시지를 곧바로 오류로 판단할 필요는 없습니다.
무선 네트워크에서 유선 네트워크로 전환하거나 한 액세스 포인트에서 다른 액세스 포인트로 이동하면 로컬 인터페이스와 기본 게이트웨이가 바뀝니다. 잘 설계된 클라이언트는 네트워크 변화를 감지하고 연결을 다시 만듭니다. 화면에 계속 연결됨으로 표시되지만 웹페이지가 열리지 않는다면 수동으로 연결을 끊었다가 다시 연결하는 것은 임시 조치일 뿐입니다. 장기적으로는 클라이언트가 자동으로 복구하는지, 로컬 네트워크에 접근할 수 없는 이전 라우팅을 남기는지 확인해야 합니다.
iCloud, iMessage와 Apple 서비스의 공존 방식
Apple 서비스는 하나의 웹사이트가 아닙니다. iCloud 동기화, iMessage, App Store, 시스템 업데이트, 푸시와 기기 연속성 기능은 서로 다른 도메인과 네트워크 엔드포인트에 접속하며, 연결은 지역과 네트워크 환경에 따라 달라질 수 있습니다. 특정 도메인을 직접 연결 목록에 추가하는 것만으로는 일부 요청만 해결할 수 있으며, Apple 서비스 전체가 제대로 분할 라우팅된다고 볼 수 없습니다.
더 안정적인 원칙은 국제 회선이 필요한 트래픽만 규칙에 따라 원격으로 보내고, Apple 계정·시스템 업데이트·로컬 서비스는 기존 네트워크 경로를 우선 유지하는 것입니다. 이렇게 하면 로그인 환경이 자주 바뀌는 일을 줄이고 대용량 동기화가 원격 회선을 점유하는 것도 피할 수 있습니다. 클라이언트는 도메인 규칙, IP 규칙과 최종 기본 정책을 지원하고 DNS 조회와 라우팅 규칙의 관계를 명확히 설명해야 합니다.
분할 라우팅 규칙은 도메인 목록만 봐서는 안 됩니다
도메인 규칙은 요청 대상을 식별하고 IP 규칙은 이미 주소를 얻은 연결을 처리하며, 두 규칙 사이를 DNS 해석이 이어 줍니다. DNS는 로컬에서 해석하면서 연결은 원격으로 보내면 로컬 네트워크에 더 적합한 주소가 반환될 수 있습니다. 반대로 모든 DNS를 원격에서 처리하면 로컬 서비스와 로컬 네트워크 이름을 정상적으로 해석하지 못할 수 있습니다. 따라서 신뢰할 수 있는 클라이언트는 모든 조회를 하나의 서버로 보내는 대신 DNS 정책과 분할 라우팅 규칙을 함께 조정할 수 있어야 합니다.
DNS 누출의 핵심은 DNS 조회가 예상한 경로로 전송되지 않아 접속 대상이 로컬 DNS 서비스에 노출되거나, 해석 결과와 실제 출구가 일치하지 않는 것입니다. 확인할 때는 출구 주소만 보지 말고 현재 모드에 맞는 DNS 해석 주체인지도 확인해야 합니다. 규칙 기반 분할 라우팅을 사용한다면 로컬 트래픽은 로컬 DNS를 사용하고 원격 트래픽은 회선에 맞는 DNS를 사용하는 방식이 일반적입니다. 구체적인 구현은 클라이언트 코어와 규칙 기능에 따라 달라집니다.
iCloud Private Relay와 서드파티 터널은 역할이 다릅니다. iCloud Private Relay는 Apple이 설계한 특정 트래픽 범위를 주로 처리하고, VPN 또는 프록시 클라이언트는 더 넓은 앱 연결을 제어할 수 있습니다. 둘을 동시에 활성화하면 시스템이 네트워크 정책에 따라 사용 가능 상태를 조정할 수 있습니다. Apple 서비스에 문제가 생겼을 때는 여러 개인정보 보호 및 프록시 기능을 모두 켜고 충돌 원인을 추측하기보다, 현재 어떤 구성 요소가 트래픽을 처리하는지 먼저 확인해야 합니다.
- 회선에 연결하지 않은 상태에서 iCloud 동기화, iMessage와 App Store가 정상적으로 작동하는지 먼저 확인합니다.
- 규칙 모드를 활성화하고 실제로 필요한 대상만 국제 회선으로 보냅니다.
- Apple 서비스를 다시 확인하고 계정에서 반복적으로 인증이나 재연결을 요구하는지 관찰합니다.
- 출구와 DNS를 확인해 브라우저 트래픽과 Apple 서비스가 각각 예상한 경로를 사용하는지 검증합니다.
- 문제가 발생하면 추가 필터 도구를 먼저 비활성화한 뒤 충돌 범위를 단계적으로 좁힙니다.
M 시리즈 칩 호환성: 네이티브 앱과 네이티브 코어는 다릅니다
M 시리즈 Mac은 Apple Silicon 아키텍처를 사용합니다. 클라이언트가 설치된다고 해서 모든 구성 요소가 네이티브로 맞춰졌다는 뜻은 아닙니다. 그래픽 인터페이스, 네트워크 확장, 프록시 코어, 업데이트 프로그램과 명령줄 보조 도구가 서로 다른 아키텍처를 사용할 수 있으며, 어느 한 단계라도 변환 실행에 의존하면 시작, 업그레이드 또는 백그라운드 실행에 영향을 줄 수 있습니다.
확인할 때는 시스템의 활성 상태 보기에서 앱 프로세스 유형을 확인하거나 앱 정보에서 범용 버전인지 Apple Silicon 전용인지 살펴볼 수 있습니다. 더 중요한 것은 메인 화면만 확인하지 말고 클라이언트 연결 후 실제로 실행되는 네트워크 코어와 확장을 관찰하는 것입니다. 일부 클라이언트는 외부 셸만 네이티브화하고 내부 코어는 여전히 변환 실행할 수 있습니다. 평소에는 차이가 드러나지 않다가 코어를 업그레이드하거나 연결을 복구할 때 문제가 나타납니다.
Rosetta는 호환성을 제공하지만 장기 판단에서 놓치면 안 됩니다
Rosetta는 Apple Silicon에서 이전 아키텍처용으로 빌드된 앱을 실행하도록 돕습니다. Rosetta 자체가 오류 신호는 아니며, 완성도 높은 소프트웨어는 변환 실행을 통해서도 안정적으로 작동할 수 있습니다. 다만 비슷한 클라이언트에 네이티브 버전이 이미 있다면 이후 유지 관리가 쉽고 메인 프로그램, 확장과 코어의 아키텍처 불일치로 인한 문제 해결 비용도 줄일 수 있으므로 네이티브 빌드를 우선 선택하는 편이 좋습니다.
이전 Mac에서 옮겨 온 앱은 마이그레이션 도구로 복사한 프로그램과 보조 구성 요소를 그대로 사용하기보다 현재 버전을 다시 다운로드하는 것이 좋습니다. 기존 설정은 별도로 백업할 수 있지만 네트워크 확장과 백그라운드 구성 요소는 새 설치 프로그램으로 다시 등록하는 편이 안전합니다. 클라이언트 업그레이드 후 연결되지 않는다면 구독이나 회선을 초기화하기 전에 코어 파일이 완전히 업데이트됐는지 먼저 확인하세요.
프로토콜 선택: 이름뿐 아니라 클라이언트 구현도 확인해야 합니다
Mac 구독 클라이언트에서 흔히 사용하는 프로토콜로는 Shadowsocks, VMess, Trojan, VLESS, Hysteria2와 TUIC가 있습니다. 각 프로토콜은 핸드셰이크, 암호화, 전송과 혼잡 제어 방식이 다르지만 프로토콜 자체가 macOS 권한, DNS 또는 분할 라우팅 문제를 자동으로 해결해 주지는 않습니다. 같은 프로토콜이라도 클라이언트에 따라 안정성이 다른 경우가 많으며, 그 차이는 네트워크 코어 버전, 가상 네트워크 인터페이스 구현, 규칙 엔진과 오류 복구 로직에서 비롯됩니다.
| 프로토콜 또는 방식 | 핵심 이해 사항 | Mac에서 확인할 항목 |
|---|---|---|
| Shadowsocks | 프록시 프로토콜로 자주 사용되며 시스템 프록시 또는 가상 네트워크 인터페이스와 함께 트래픽을 제어할 수 있습니다 | UDP 지원, DNS 정책과 시스템 프록시를 따르지 않는 앱의 처리 방식을 확인합니다 |
| VMess / VLESS | 일반적으로 범용 프록시 코어가 처리하며 여러 전송 방식을 조합할 수 있습니다 | 코어가 지속적으로 유지 관리되는지, 구독 필드를 클라이언트가 완전히 인식하는지 확인합니다 |
| Trojan | TLS 연결 특성을 기반으로 하며 인증서와 서버 이름이 올바르게 일치해야 합니다 | 시스템 시간, 인증서 검증과 클라이언트 TLS 구현에서 문제가 발생했을 때 각각 따로 확인합니다 |
| Hysteria2 / TUIC | UDP 기반 전송을 활용해 특정 네트워크에서 처리량과 응답성을 개선하는 경우가 많습니다 | 현재 네트워크에서 안정적인 UDP 통신이 가능한지 먼저 확인하고 전환 가능한 예비 프로토콜을 준비합니다 |
사용 중인 네트워크가 UDP에 적합하지 않다면 Hysteria2 또는 TUIC의 특성이 제대로 발휘되지 않거나 핸드셰이크가 바로 실패할 수 있습니다. 이때는 무관한 매개변수를 반복해서 수정하기보다 사용할 수 있는 TCP 또는 TLS 방식을 선택하는 편이 효과적입니다. 반대로 UDP 환경이 양호하더라도 프로토콜 이름만으로 더 빠르다고 단정할 수는 없습니다. 회선 부하, 라우팅 품질과 클라이언트 구현이 여전히 사용 경험에 영향을 줍니다.
IEPL 전용 회선, 중계와 직접 연결은 회선 경로를 설명하는 용어이지 클라이언트 프로토콜이 아닙니다. 직접 연결은 일반적으로 로컬 네트워크에서 원격 입구까지 바로 연결되어 경로가 단순하지만 공용망 라우팅 품질에 더 크게 의존합니다. 중계는 먼저 중간 입구로 연결한 뒤 대상 출구로 전달해 일부 경로를 최적화할 수 있습니다. IEPL 전용 회선은 지역 간 전송 구간에 더 통제하기 쉬운 전용 네트워크 자원을 사용한다는 점을 강조합니다. 클라이언트는 여전히 구체적인 프로토콜로 연결을 설정하므로 전용 회선과 VLESS는 서로 배타적인 선택지가 아니며 같은 수준에서 직접 비교해서도 안 됩니다.
구독 가져오기 및 업데이트: 출처를 먼저 확인하고 노드를 살펴보세요
구독 링크는 클라이언트가 회선 구성을 가져오는 입구입니다. 가져오기 전에 링크가 서비스 패널에서 제공된 것인지, 클라이언트가 지원하는 구독 유형인지 확인하세요. 구독 링크는 일반적으로 회선 구성을 바로 읽을 수 있으므로 공개 채팅, 스크린샷 또는 공유 문서에 보내지 마세요. 유출이 의심되면 로컬에서 클라이언트만 삭제하지 말고 서비스 패널에서 재설정해야 합니다.
가져오기가 끝나면 먼저 노드 이름, 프로토콜 유형과 그룹이 모두 표시되는지 확인한 뒤 회선을 선택하세요. 클라이언트에 업데이트 성공이라고 표시되는 것은 요청 결과가 반환됐다는 뜻일 뿐, 모든 필드가 올바르게 해석됐다는 의미는 아닙니다. 일부 노드가 사라지거나 전송 매개변수가 누락되거나 프로토콜을 인식하지 못한다면 해당 구독 내용을 클라이언트 코어가 지원하는지 우선 확인해야 합니다.
일부 앱은 구독 업데이트를 현재 연결과 연동합니다. 업데이트 중 잠시 연결을 끊고 완료 후 정책을 다시 선택하는 방식이 있는가 하면, 백그라운드에서 구성을 교체하는 방식도 있습니다. 어떤 방식을 사용하든 업데이트 후 기존 분할 라우팅 규칙이 여전히 유효한지 확인해야 합니다. 직접 관리하는 로컬 규칙은 원격 구독과 분리해 저장하는 것이 좋으며, 한 번의 업데이트로 개인 설정이 덮어쓰이는 일을 피할 수 있습니다.
로컬 확인 순서
클라이언트 버전 및 칩 아키텍처
네트워크 확장 또는 시스템 프록시 상태
구독 업데이트 및 프로토콜 해석
현재 회선 핸드셰이크 상태
기본 라우팅 및 분할 라우팅 규칙
출구 주소 및 DNS 경로
Apple 서비스 및 로컬 네트워크 접근
잠자기 복귀 후 자동 복구재현 가능한 로컬 실사용 테스트 절차
Mac VPN 또는 국제 회선 서비스를 선택할 때는 다른 사람의 속도 측정 스크린샷만 보지 말고 자신의 네트워크 환경에서 재현해 보는 것이 좋습니다. 공용망 경로, 연결 방식, DNS와 로컬 소프트웨어 환경이 결과를 바꿀 수 있습니다. 다음 절차는 복잡한 장비를 요구하지 않고, 연결된다는 상태를 항목별로 확인할 수 있도록 나눠 설명합니다.
- 기준 상태를 설정합니다. 다른 네트워크 도구를 종료하고 연결하지 않은 상태에서 웹페이지 접속, Apple 서비스, 로컬 네트워크 기기와 DNS가 정상인지 기록합니다.
- 권한을 완료합니다. 후보 클라이언트를 실행하고 필요한 VPN 구성 또는 네트워크 확장을 허용한 뒤 시스템 설정과 클라이언트 모두에서 활성화 상태인지 확인합니다.
- 구독을 가져옵니다. 서비스 패널에서 구독 링크를 복사하고 가져온 뒤 구성을 업데이트합니다. 프로토콜, 그룹과 회선이 모두 표시되는지 확인합니다.
- 출구를 확인합니다. 대상 회선에 연결한 뒤 출구 주소를 확인하고 현재 전역 모드 또는 규칙 모드에 맞게 DNS가 작동하는지도 살펴봅니다.
- 분할 라우팅을 검증합니다. 국제 회선이 필요한 대상, 로컬 웹사이트, Apple 서비스와 로컬 네트워크 리소스를 각각 열어 각 경로가 예상과 일치하는지 확인합니다.
- 네트워크 변화를 만듭니다. 네트워크를 전환하거나 Mac을 잠자기 상태로 전환한 뒤 복귀하고, 클라이언트가 터널을 다시 설정하는지 이전 라우팅이 올바르게 교체되는지 확인합니다.
- 비정상 종료를 확인합니다. 클라이언트 연결을 정상적으로 끊고 종료한 뒤 시스템 프록시, DNS와 로컬 네트워크가 복구되는지 확인합니다. 수동으로 정리해야 하는 설정이 남아 있어서는 안 됩니다.
테스트 중에는 한 번에 하나의 변수만 변경하세요. 예를 들어 클라이언트와 프로토콜을 고정한 뒤 회선만 바꾸거나, 회선을 고정하고 시스템 프록시와 가상 네트워크 인터페이스 모드만 비교할 수 있습니다. 클라이언트, 프로토콜, 회선과 DNS를 동시에 바꾸면 문제가 어디에서 발생했는지 판단할 수 없습니다. 로그도 작업 시간과 함께 읽고 연결, 라우팅, DNS와 재연결이 어떤 순서로 발생했는지에 집중해야 합니다.
속도 테스트는 보조 자료로 활용할 수 있지만 안정성 판단을 대신해서는 안 됩니다. 일상적인 Mac 사용에서는 Apple 서비스가 정상 작동하는지, 네트워크 전환 후 복구되는지, DNS 경로가 잘못 매칭되지 않는지가 짧은 순간의 최고 속도보다 중요한 경우가 많습니다. 동영상, 개발 도구, 클라우드 동기화와 원격 근무는 요구하는 네트워크 조건이 다르므로 주로 사용하는 앱에 맞춰 최종 모드를 선택해야 합니다.
최종 선택: 안정성, 분할 라우팅과 유지 관리를 함께 고려하세요
Mac VPN 추천은 노드 수나 프로토콜 이름만 비교해서는 충분하지 않습니다. macOS에 더 적합한 방식이라면 네트워크 확장 권한을 명확히 안내하고, 확인 가능한 연결 상태를 제공하며, DNS와 라우팅을 함께 조정하는 분할 라우팅을 지원해야 합니다. 또한 메인 프로그램, 확장과 프록시 코어가 M 시리즈 칩에서 일관되게 유지 관리되어야 합니다.
주요 요구가 브라우저 접속이라면 시스템 프록시와 신뢰할 수 있는 규칙만으로도 충분할 수 있습니다. 터미널, 독립 데스크톱 앱과 복잡한 분할 라우팅까지 사용한다면 네트워크 확장 또는 가상 네트워크 인터페이스 모드가 더 적합합니다. iCloud, iMessage와 App Store를 자주 사용한다면 Apple 서비스 경로를 안정적으로 유지하고 계정 관련 트래픽의 출구를 자주 바꾸지 않는 것을 우선해야 합니다.
프로토콜 선택은 현재 네트워크 조건에 따라야 합니다. UDP 환경이 양호하다면 Hysteria2 또는 TUIC를 테스트할 수 있지만, 호환성을 우선할 때는 다른 사용 가능한 전송 방식도 남겨 두어야 합니다. 회선은 직접 연결, 중계 또는 IEPL 전용 회선의 실제 성능을 기준으로 판단하고 회선 경로와 프록시 프로토콜을 혼동하지 마세요.