재택근무에서는 웹 브라우징보다 화상회의와 실시간 협업 도구의 연결 품질이 더 중요합니다. v2rayN을 실행한 뒤 모든 트래픽을 무조건 프록시로 보내면 Zoom이나 Google Meet은 연결되더라도 국내 업무 사이트, 사내 시스템, 프린터 검색이 느려질 수 있습니다. 반대로 필요한 업무 서비스만 프록시로 보내면 회의는 안정적으로 유지하면서 일반 국내 트래픽은 기존 회선을 사용할 수 있습니다.
v2rayN 7.x를 기준으로 Zoom·Slack·Google Meet을 업무용 프록시 경로로 보내고 국내 서비스는 직결하는 설정을 설명합니다. 먼저 Xray 코어와 로컬 포트를 확인한 다음 노드의 실제 지연 시간과 손실을 비교하고, 도메인 규칙·UDP·시스템 프록시를 순서대로 조정합니다. 회의 전 10분 점검 절차와 연결이 불안정할 때 확인할 항목도 함께 정리합니다.
재택근무용 분할 라우팅의 기본 구조
v2rayN에서 선택한 서버는 애플리케이션의 요청을 바로 인터넷으로 전달하는 것이 아니라, 먼저 클라이언트의 로컬 인바운드 포트로 요청을 받습니다. 그 뒤 라우팅 규칙이 도메인·IP·포트 등의 조건을 검사하고, 일치하는 요청을 프록시 출구 또는 직결 출구로 나눕니다. Windows 시스템 프록시를 켜면 HTTP 프록시를 따르는 프로그램이 보통 로컬 HTTP 포트로 연결되며, SOCKS를 직접 지원하는 프로그램은 SOCKS 포트를 사용할 수 있습니다.
업무용 구성에서는 세 가지 경로를 분리해 생각하는 것이 좋습니다. Zoom·Google Meet처럼 실시간 미디어를 사용하는 서비스는 업무용 프록시 출구로 보내고, Slack의 웹·데스크톱 연결은 필요한 도메인만 같은 출구로 보냅니다. 국내 은행, 공공기관, 사내 주소처럼 직결이 더 적합한 대상은 direct로 처리합니다. 그 밖의 주소는 기본 정책에 따라 결정하되, 처음에는 규칙을 지나치게 넓게 잡지 않는 편이 장애 원인을 찾기 쉽습니다.
| 트래픽 유형 | 권장 경로 | 확인할 점 |
|---|---|---|
| Zoom 회의 신호와 미디어 | 업무용 프록시 | UDP 허용 여부, 실제 회의 중 패킷 손실 |
| Slack 웹소켓과 파일 전송 | 업무용 프록시 | 443 연결 유지, 워크스페이스 주소의 규칙 포함 |
| Google Meet 신호와 미디어 | 업무용 프록시 | UDP 우선 연결, 브라우저 권한과 마이크 상태 |
| 국내 사이트·사내망 | 직결 또는 회사 VPN | 회사 보안 정책, 내부 DNS, 접근 IP 제한 |
노드와 코어를 먼저 고르는 방법
화상회의에서는 단순히 목록에서 가장 작은 지연 시간만 고르면 안 됩니다. TCP 탐지 결과가 40ms로 표시되어도 실제 프록시 핸드셰이크가 150ms를 넘거나, 회의가 시작된 뒤 5분마다 순간적인 끊김이 발생할 수 있습니다. 같은 Wi-Fi와 같은 시간대에서 후보 노드를 세 번 측정하고, 최저값보다 중앙값과 변동 폭을 기록하세요. 예를 들어 72·78·81ms인 노드는 55·180·시간 초과인 노드보다 회의용 주 노드로 적합할 가능성이 높습니다.
v2rayN의 서버 목록에서 후보 그룹을 10~30개로 좁힌 뒤 마우스 오른쪽 메뉴의 실제 연결 지연 테스트를 실행합니다. 테스트 도중 대용량 다운로드나 클라우드 동기화를 멈추고, 같은 노드에 연결한 상태에서 60초 정도 음성·영상 테스트를 진행합니다. 회의 화면의 수신 영상이 깨지는지, 음성이 로봇처럼 들리는지, 화면 공유가 늦게 따라오는지까지 확인해야 합니다.
VLESS, REALITY, Vision과 최신 전송 조합을 사용하는 구독에 적합합니다. 노드 링크에 security=reality, pbk, sid 또는 flow=xtls-rprx-vision이 있으면 Xray 코어를 우선 확인하세요.
적합: 최신 업무용 노드, VLESS·REALITY, 낮은 지연이 필요한 회의
기존 VMess, 일반 VLESS, Trojan과 WebSocket·TLS 조합을 유지해야 할 때 호환성 확인용으로 사용할 수 있습니다. 코어를 바꾼 뒤 전송 방식이나 보안 필드가 사라지지 않았는지 확인해야 합니다.
적합: 기존 VMess 설정, 표준 TLS 전송, 구형 구성 점검
회의용 주 노드는 지연 시간뿐 아니라 지터와 패킷 손실이 안정적이어야 합니다. 예비 노드는 다른 지역이나 다른 출구로 준비해 한 경로 장애에 의존하지 않도록 합니다.
적합: 주 노드 장애 대비, 장시간 회의, 화면 공유
결론: 회의용 노드는 평균값보다 변동 폭을 우선하세요
세 번 측정한 결과의 차이가 10ms 안팎이고 60초 테스트에서 음성 끊김이 없는 노드가, 한 번만 40ms를 기록한 불안정한 노드보다 실제 업무에 더 유리합니다.
v2rayN에서 규칙과 UDP를 설정하기
이제 실제 설정을 적용합니다. 메뉴 이름은 v2rayN 세부 버전에 따라 조금 다를 수 있지만, 「설정」→「매개변수 설정」→「Core 유형」에서 선택 코어를 확인하고 「설정」→「라우팅 설정」에서 규칙과 기본 출구를 조정하는 흐름은 대체로 같습니다. 기존 설정을 바로 삭제하지 말고, 변경 전 활성 서버·라우팅 모드·로컬 포트 값을 메모해 두세요.
코어 확인
「설정」→「매개변수 설정」→「Core 유형」에서 구독에 필요한 Xray 또는 V2Fly 코어를 선택합니다. VLESS·REALITY 링크인데 V2Fly로 설정되어 있다면 노드가 시작되지 않거나 필드 인식 오류가 발생할 수 있습니다.
노드 선정
서버 목록에서 10~30개 후보를 고른 뒤 실제 연결 지연을 3회 측정합니다. 중앙값이 낮고 시간 초과가 없는 노드를 두 번 클릭해 활성 서버로 지정한 다음 상태 표시줄의 서버 이름을 확인합니다.
라우팅 열기
「설정」→「라우팅 설정」에서 규칙 기반 모드를 선택합니다. Zoom·Slack·Google Meet 관련 도메인은 프록시 출구로, 국내 업무 사이트와 사내 주소는 조직 정책에 맞춰 direct 또는 회사 VPN으로 지정합니다.
UDP 점검
「설정」→「파라미터 설정」의 SOCKS 또는 TUN 관련 UDP 옵션을 확인합니다. 회의 서비스가 UDP를 사용할 수 있도록 설정하되, 현재 노드·전송 방식·네트워크가 UDP를 지원하지 않으면 TCP 443으로 동작하는 대체 경로를 준비합니다.
프록시 적용
시스템 프록시를 켜고 브라우저에서 Slack과 Google Meet을 새로 시작합니다. 로컬 SOCKS 포트가 10808, HTTP 포트가 10809인지 확인하되, 실제 포트는 「매개변수 설정」에 표시된 값을 기준으로 사용합니다.
일반 웹 업무 경로
- SOCKS
- 127.0.0.1:10808
- HTTP
- 127.0.0.1:10809
- 라우팅
- 업무 도메인 프록시
- 기본 경로
- 정책에 따른 direct
포트는 예시이며 v2rayN 화면에 표시된 실제 값을 우선합니다.
화상회의 경로
- Zoom 미디어
- UDP 우선
- Meet 미디어
- UDP 가능 여부 확인
- 신호 채널
- HTTPS·WebSocket
- 대체 경로
- TCP 443
UDP를 강제로 켜는 것보다 노드와 네트워크의 실제 지원 여부가 중요합니다.
라우팅 규칙은 서비스 이름만 보고 추측하기보다 연결 로그로 보완해야 합니다. Zoom은 회의 신호와 미디어 서버가 서로 다른 주소를 사용할 수 있고, Slack은 워크스페이스·파일·웹소켓 연결이 나뉠 수 있습니다. Google Meet도 브라우저가 여러 Google 관련 도메인과 미디어 엔드포인트를 사용합니다. 따라서 특정 도메인 하나만 추가한 뒤 완료했다고 판단하지 말고, 회의 시작·채팅·파일 업로드·화면 공유를 각각 실행하면서 로그에서 반복되는 대상과 출구를 확인하세요.
| 기능 | 테스트 방법 | 정상적인 관찰 결과 |
|---|---|---|
| 음성·영상 | 10분 테스트 회의 참여 | 음성 지연과 영상 정지가 반복되지 않음 |
| 화면 공유 | 창 공유 후 2분간 스크롤 | 화면 갱신이 수 초씩 누적되지 않음 |
| Slack 메시지 | 채널 메시지와 파일 전송 | 웹소켓 재연결 알림이 반복되지 않음 |
| 국내 서비스 | 사내 시스템과 국내 웹사이트 접속 | 필요한 경우 direct 또는 회사 VPN 정책대로 연결됨 |
회의 전 점검과 장애 대응
회의 직전에 노드를 바꾸거나 라우팅 규칙을 여러 개 수정하면 어떤 변경이 효과가 있었는지 알기 어렵습니다. 평소 사용하는 주 노드와 예비 노드를 각각 저장하고, 회의 시작 10분 전에 한 번만 연결 테스트를 수행하세요. Zoom·Slack·Google Meet을 동시에 모두 열어 두기보다 실제 회의에 사용할 앱부터 실행하고, 마이크와 카메라 권한이 정상인지 확인합니다.
회의는 연결되지만 음성이 자주 끊겨요
먼저 UDP 사용 여부와 패킷 손실을 확인하세요. UDP가 불안정하면 다른 노드로 바꾸고 TCP 443 대체 경로를 테스트합니다. 동시에 Wi-Fi 대신 유선 또는 안정적인 5GHz 네트워크를 비교하면 프록시 문제와 무선 간섭을 구분하기 쉽습니다.
Slack 메시지는 되는데 파일만 실패해요
메시지 웹소켓과 파일 업로드 대상이 다른 규칙을 사용하는지 로그에서 확인합니다. Slack 워크스페이스 주소만 프록시로 보냈다면 파일 저장 도메인이 direct로 빠질 수 있으므로 해당 요청의 출구를 일관되게 맞춰 보세요.
Google Meet에서 화면 공유가 느려요
회의 신호 연결과 화면 미디어 경로를 따로 확인합니다. 화면 공유를 시작할 때 지연이 급증하면 노드의 업로드 대역폭과 UDP 손실을 측정하고, 다른 지역의 예비 노드와 비교하세요.
국내 사이트까지 모두 느려졌어요
현재 라우팅 모드가 전역 프록시인지 확인하고 규칙 기반 모드로 되돌립니다. 국내 도메인·사내 주소가 프록시 출구로 들어가고 있지 않은지 로그에서 확인한 뒤, 회사 VPN이 필요한 주소는 임의로 direct로 우회하지 마세요.
오류: connection timeout during handshake
원인 및 해결 방법: 노드 주소나 전송 계층의 핸드셰이크가 제한 시간 안에 끝나지 않았습니다. 코어와 노드의 TLS·SNI·전송 필드를 다시 확인하고, 실제 연결 지연이 안정적인 다른 노드로 테스트하세요.
오류: UDP is not supported
원인 및 해결 방법: 현재 출구 또는 전송 방식이 UDP를 전달하지 못합니다. 노드 제공 설정을 임의로 수정하지 말고 UDP 지원 노드를 선택하거나 TCP 443 대체 경로로 회의 품질을 비교하세요.
오류: websocket closed unexpectedly
원인 및 해결 방법: Slack과 같은 장시간 웹소켓 연결이 중간에 닫혔습니다. 프록시 규칙에 워크스페이스 도메인이 포함되는지, 노드가 443 연결을 안정적으로 유지하는지, 시스템 절전이나 보안 프로그램이 연결을 끊지 않는지 확인하세요.
마지막으로 설정 변경 후에는 v2rayN 로그, 회의 앱의 통계 화면, 실제 체감 품질을 함께 기록하세요. 지연 시간이 낮아도 업로드 손실이 높으면 화면 공유가 나빠질 수 있고, 속도가 빠른 노드라도 저녁 시간에 지터가 커지면 음성 품질이 떨어질 수 있습니다. 주 노드·예비 노드·직결 규칙을 각각 확인 가능한 상태로 유지하면 다음 회의에서 문제를 빠르게 분리할 수 있습니다.