Windows VPN 추천:전역 프록시와 분할 터널링 비교, 게임·업무 호환과 자동 시작 실측

Windows VPN 데스크톱 설정에서 전역 프록시와 분할 터널링은 가장 먼저 결정해야 할 선택입니다. 전자는 PC 전체 트래픽을 회선으로 보내고, 후자는 규칙에 걸린 요청만 처리합니다. 두 모드에 절대적인 우열은 없고 차이는 게임, 업무용 앱, 브라우저에서 드러납니다. 잘못 고르면 게임 지연이 올라가거나 사내망 로그인이 시간 초과되거나 브라우저가 프록시에 연결할 수 없다는 메시지를 띄웁니다. 이 글에서는 상황별로 두 모드를 비교하고, 분할 터널링 규칙 작성법과 시스템 프록시 인수, 부팅 시 자동 시작 설정 단계, 연결 이상 시 점검 순서를 정리합니다.

전역 프록시와 분할 터널링: 두 모드의 실제 차이

전역 프록시는 전역 모드라고도 합니다. 켜면 클라이언트가 PC의 모든 아웃바운드 트래픽을 회선으로 보내며, 목적지가 중국 본토인지 해외인지 따지지 않습니다. 장점은 동작이 예측 가능하다는 점입니다. 어떤 앱도 로컬 네트워크로 새지 않고, 문제를 볼 때 링크 하나만 확인하면 됩니다. 대가는 분명합니다. 중국 본토 사이트도 노드를 거쳐 돌아오므로 지연이 회선 출구 위치에 좌우되고, 프린터·NAS·화면 미러링 같은 로컬 네트워크 기기와 사내 시스템까지 함께 인수되어 아예 쓸 수 없게 되는 경우가 많습니다.

분할 터널링 모드는 규칙표를 한 줄씩 판단합니다. 직접 연결 규칙에 걸린 연결은 로컬 네트워크로, 프록시 규칙에 걸린 연결은 회선으로 보내고, 둘 다 해당하지 않으면 마지막 기본 규칙이 처리합니다. 효과는 규칙표 품질에 달려 있지만, 관리가 정상이라면 중국 본토 사이트 속도는 프록시를 켜지 않았을 때와 비슷하고 사내 기기도 그대로 쓸 수 있으며 해외 접속이 필요한 도메인과 프로세스만 회선을 탑니다.

세 번째로 직접 연결 모드가 있습니다. 프록시를 잠시 끄되 클라이언트는 종료하지 않는 방식으로, 시스템 업데이트나 로컬 네트워크 디버깅처럼 완전한 로컬 환경이 필요한 상황에 맞습니다.

회선 조건도 두 모드의 성능에 영향을 줍니다. VPNPF를 예로 들면 회선 유형은 IEPL 전용선, 중계, 직접 연결을 아우르며 지역과 회선 규모는 다음과 같습니다.

분할 터널링에서는 목적지 위치에 맞춰 노드를 고르면 됩니다. 지역과 회선 유형을 하나씩 확인하려면 회선 페이지를 참고하세요.

분할 터널링 규칙 작성법: 도메인·프로세스·IP 대역 매칭 순서

분할 터널링 규칙표는 위에서 아래로 내려가며 일치하면 멈추는 방식으로 동작합니다. 개수보다 순서가 중요합니다. 정확한 규칙을 앞에, 넓은 규칙을 뒤에 두고 마지막에 기본 규칙을 하나 남깁니다.

세 가지 매칭 방식이 각각 해결하는 문제

• 도메인 매칭: DOMAIN은 도메인 하나를 정확히 매칭하고, DOMAIN-SUFFIX는 도메인 접미사 전체를, DOMAIN-KEYWORD는 키워드로 매칭합니다. 웹사이트, API, 소프트웨어 업데이트 서버에 쓰이며 유지 관리 비용이 가장 낮습니다.
• 프로세스 매칭: PROCESS-NAME은 실행 파일 이름으로 판단하며 데스크톱 앱에 적합합니다. 게임 실행 파일은 직접 연결로, 브라우저는 프록시로 지정하는 방식은 게임과 업무를 한 PC에서 함께 쓸 때 가장 흔히 쓰입니다. 프로세스 이름은 작업 관리자에 표시되는 이름과 같아야 합니다.
• IP 대역 매칭: IP-CIDR은 대상 네트워크 대역으로 판단하며, 주로 사내 주소(10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)와 고정 출구 서버를 처리합니다.

규칙 순서: 정확한 것 먼저, 넓은 것 나중

rem 분할 터널링 규칙 예시: 위에서 아래로 매칭, 일치 시 중단
IP-CIDR,10.0.0.0/8,DIRECT
IP-CIDR,172.16.0.0/12,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT
DOMAIN-SUFFIX,company.example,DIRECT
PROCESS-NAME,game.exe,DIRECT
DOMAIN-SUFFIX,example-intl.com,PROXY
MATCH,PROXY

클라이언트마다 필드 이름과 표기법이 조금씩 다르므로 위 예시는 순서만 보여줍니다. 사내 대역과 기업 도메인을 먼저 직접 연결로 두고, 회선을 태울 도메인과 프로세스를 따로 지정한 뒤 마지막에 기본 규칙을 둡니다. MATCH 같은 기본 규칙을 맨 앞에 두면 뒤의 규칙은 하나도 적용되지 않습니다.

구독을 가져온 뒤에도 규칙을 직접 추가해야 할까

구독을 가져오면 클라이언트 기본 규칙 세트가 대부분의 사이트와 지역 분류를 이미 포함합니다. 대다수 사용자가 추가할 것은 두 가지뿐입니다. 사내 도메인과 IP 대역, 그리고 자주 쓰는 게임이나 업종별 소프트웨어 프로세스입니다. 규칙을 고친 뒤에는 하나씩 확인하는 편이 좋습니다. 대상 사이트나 앱을 열고 클라이언트 연결 로그에서 해당 연결이 직접 연결인지 회선인지 확인하세요. 감으로 판단하지 마세요.

게임과 업무용 앱: 호환성 차이는 어디서 생기나

같은 클라이언트를 써도 게임과 업무용 앱의 동작은 자주 완전히 다릅니다. 프록시 설정을 읽는 방식이 서로 다르기 때문입니다.

게임: 대부분 시스템 프록시를 읽지 않음

주요 게임 클라이언트와 대전 트래픽은 대개 자체 UDP 채널을 쓰며 Windows 시스템 프록시 설정을 읽지 않습니다. 즉 시스템 프록시만 켜면 게임은 회선을 전혀 타지 않고 프록시를 켜지 않은 것과 같습니다. 게임을 회선에 태우려면 클라이언트가 TUN 또는 가상 네트워크 어댑터 모드를 제공해야 합니다. 가상 어댑터가 시스템 계층에서 트래픽을 인수한 뒤 규칙에 따라 회선 또는 직접 연결을 결정합니다. 대전 경험은 회선 유형이 좌우합니다. 직접 연결 회선은 경로가 가장 짧고, 중계는 입구와 출구 사이에 한 홉이 더 붙으며, IEPL 전용선은 전용 링크를 써서 피크 시간대에 더 안정적입니다. 중국 서버 게임은 직접 연결을, 해외 서버 게임은 서버 지역에 맞춰 노드를 고르세요.

업무용 앱: 사내망과 회의가 문제가 잦은 지점

• 기업 OA, 메일 서버, 코드 저장소는 기업 도메인이나 사내 IP 아래에 있는 경우가 많습니다. 이런 주소는 반드시 직접 연결로 보내야 합니다. 그렇지 않으면 로그인이 시간 초과되거나 인증 창이 반복해서 뜹니다.
• 회의와 온라인 문서는 UDP와 대역폭에 민감하고, 통화 중에 노드를 바꾸면 연결이 바로 끊깁니다. 회의 전에 회선을 고정해 두는 편이 좋습니다.
• 일부 업무용 앱은 시스템 프록시와 별개로 자체 프록시 설정을 가집니다. TUN 모드에서는 보통 따로 설정할 필요가 없고, 시스템 프록시 모드에서 해당 앱이 동작하지 않으면 그 앱의 네트워크 옵션을 확인하세요.

브라우저: 시스템 프록시를 따르되 이중 프록시는 피하기

Chrome과 Edge는 기본적으로 시스템 프록시 설정을 읽고, Firefox는 자체 네트워크 설정에서 따로 지정할 수 있습니다. 브라우저 확장 프록시와 클라이언트 프록시를 동시에 켜면 요청이 확장을 거쳐 클라이언트로 가면서 속도가 느려지거나 일부 사이트가 열리지 않습니다. 한 겹만 남기세요.

시스템 프록시 인수와 자동 시작 설정 단계

아래 순서는 Windows 10과 Windows 11의 공통 화면을 기준으로 정리했으며, 클라이언트마다 위치는 조금씩 달라도 판단 기준은 같습니다.

1. 먼저 클라이언트에서 모드를 고릅니다. 평소에는 분할 터널링(규칙 모드)을 쓰고, '특정 앱이 계속 회선을 타지 않는다'를 확인할 때만 잠시 전역으로 바꿉니다.
2. 클라이언트의 '시스템 프록시' 스위치를 켠 뒤 Windows 설정 → 네트워크 및 인터넷 → 프록시에서 주소와 포트가 클라이언트 표시와 같은지 확인합니다. 흔한 로컬 주소는 127.0.0.1이고 포트는 클라이언트가 지정합니다.
3. 게임이나 시스템 프록시를 읽지 않는 앱까지 인수해야 할 때 TUN / 가상 네트워크 어댑터 모드를 켜고, 시스템 팝업에서 드라이버 설치를 허용합니다.
4. 클라이언트 설정에서 '부팅 시 자동 시작'을 켭니다. 재부팅 후 작업 관리자 → 시작 프로그램 탭에서 클라이언트가 '사용' 상태인지, 시스템 최적화 도구나 보안 프로그램이 꺼 두지 않았는지 확인합니다.
5. '종료 시 시스템 프록시 복원' 같은 옵션이 켜져 있는지 확인합니다. 클라이언트가 비정상 종료된 뒤 브라우저가 더 이상 수신하지 않는 로컬 포트를 가리키는 일을 막아 줍니다.
6. 구독을 업데이트해 회선 목록이 최신인지 확인한 뒤 지역에 맞춰 노드를 고릅니다. 게임 서버를 바꾸기 전에 회선을 먼저 바꾸고, 게임 실행 중에는 바꾸지 마세요.

연결 이상 시 점검 순서

아래 순서대로 하나씩 확인하면 대부분의 문제는 처음 세 단계에서 원인이 잡힙니다.

• ✅ 먼저 클라이언트가 실행 중인지 확인하세요. 시스템 프록시는 로컬 포트를 가리키므로 클라이언트가 종료되면 포트가 더 이상 수신하지 않고 브라우저는 곧바로 프록시 오류를 냅니다.
• ✅ 다음은 모드입니다. 게임은 시스템 프록시를 읽지 않아 TUN / 가상 네트워크 어댑터 모드만 인수할 수 있고, 브라우저는 반대로 시스템 프록시로 충분합니다.
• ✅ DNS가 연결과 함께 회선을 타는지 확인하세요. nslookup으로 조회 출구 IP를 보면 되고, 여전히 로컬 통신사 주소라면 DNS 요청이 프록시를 타지 않은 것이며 DNS 누출이 있는 것입니다.
• ✅ IPv6를 확인하세요. 일부 네트워크는 IPv4와 IPv6를 함께 내려보내는데, 클라이언트가 IPv4만 인수하면 트래픽이 회선을 비껴갑니다. 어댑터 설정에서 IPv6를 잠시 끄고 결과를 비교해 보세요.
• ✅ 구독이 최신인지 확인하세요. 회선이 조정되면 예전 노드는 작동하지 않으므로 구독을 업데이트하고 다시 시도하세요.
• ❌ 클라이언트가 실행 중일 때 Windows 프록시 설정의 주소와 포트를 직접 바꾸지 마세요. 양쪽이 어긋나면 브라우저의 모든 요청이 실패합니다.
• ❌ 구독 링크를 공개하지 마세요. 링크에 계정 자격 증명이 들어 있어 링크를 받은 사람이 그대로 쓸 수 있습니다.

rem WinHTTP 계층의 현재 프록시 설정 확인
netsh winhttp show proxy

rem WinHTTP 프록시를 비우고 직접 접속으로 복원
netsh winhttp reset proxy

rem DNS 캐시 새로 고침
ipconfig /flushdns

rem 조회 요청의 출구 IP를 확인해 DNS가 회선을 타는지 판단
nslookup -type=txt o-o.myaddr.l.google.com

Windows 프록시 설정은 두 계층으로 나뉩니다. 브라우저와 대부분의 데스크톱 앱은 '설정 → 프록시'의 WinINET 구성을 읽고, 시스템 서비스와 업데이트 프로그램은 WinHTTP를 읽습니다. 두 계층을 따로 설정하고 점검할 때도 각각 확인하면 시행착오를 줄일 수 있습니다.

결론: 전역과 분할 터널링이 각각 맞는 상황

결론을 세 문장으로 압축하면 이렇습니다. 장기 사용에는 분할 터널링, 임시 전체 인수에는 전역을 고르세요. 브라우저와 시스템 프록시를 읽는 앱은 시스템 프록시에, 게임과 시스템 프록시를 읽지 않는 프로그램은 TUN에 맡기세요. 부팅 시 자동 시작을 켜고 '종료 시 시스템 프록시 복원'도 켜 두세요. 이 두 가지가 프록시 상태를 통제할 수 있는지를 함께 결정합니다.