재택근무 중 Zoom이나 Teams 회의에서 음성이 끊기거나 화면이 멈추면, 원인을 곧바로 노드 속도로 단정하기 어렵습니다. Wi-Fi 품질, 회사 네트워크의 UDP 제한, Shadowrocket의 Global Routing, 서비스별 규칙이 함께 영향을 줄 수 있습니다. 먼저 같은 네트워크에서 프록시를 끈 상태와 켠 상태를 비교하고, 회의 트래픽을 직접 연결할지 프록시로 보낼지 확인하세요.
이 글은 본인의 구독과 연결 항목을 이미 보유한 사용자를 위한 재택근무 설정 안내입니다. 회의 트래픽을 앱별로 지정하는 설정과 도메인 규칙에 따른 분할 라우팅은 다르다는 점을 짚고, UDP와 네트워크 상태를 확인한 뒤 Zoom·Teams 관련 요청을 직접 연결하거나 프록시로 보내는 방법을 설명합니다. 서비스별 도메인은 환경에 따라 달라질 수 있으므로, 예시 규칙을 그대로 적용하기보다 실제 요청 기록과 회사의 네트워크 정책을 확인하세요. 구독 링크는 이용 중인 서비스 제공업체에서 받으세요.
화상회의 트래픽과 라우팅을 먼저 구분하기
회의 앱은 로그인, 일정, 채팅, 이미지, 음성·영상 미디어 등 여러 종류의 요청을 보낼 수 있습니다. 이 요청들이 항상 같은 서버나 같은 전송 방식만 사용하는 것은 아닙니다. 따라서 회의 앱의 웹사이트 도메인 하나만 직접 연결하면 모든 음성·영상 트래픽이 같은 경로로 바뀐다고 볼 수 없습니다. 회의에 필요한 주소는 서비스 구성, 계정, 지역, 조직 설정에 따라 달라질 수 있습니다.
Shadowrocket의 규칙은 일반적으로 요청의 도메인이나 IP 주소 같은 조건을 기준으로 정책을 적용합니다. iPhone 또는 iPad에서 특정 앱 이름을 선택해 그 앱의 모든 연결을 자동 분기하는 방식과는 구분해야 합니다. 사용자가 말하는 ‘앱별 라우팅’을 규칙으로 구현하려면 앱 자체가 아니라 해당 앱에서 발생한 네트워크 요청을 식별할 수 있는 조건이 필요합니다. 식별할 수 없는 요청에는 의도한 규칙이 적용되지 않을 수 있습니다.
Global Routing의 Proxy와 규칙의 PROXY는 같은 표시처럼 보여도 쓰이는 위치가 다릅니다. Home → Global Routing에서 Proxy를 선택하면 전역 라우팅 방식이 바뀌고, Config의 규칙에서 PROXY를 사용하면 해당 규칙에 일치한 요청을 프록시로 보냅니다. Direct는 현재 네트워크를 통해 직접 연결하는 선택이며, 회사의 보안 정책이나 방화벽을 우회하는 기능은 아닙니다.
회의 트래픽을 직접 연결할지 프록시로 보낼지
두 경로 중 어느 쪽이든 모든 네트워크에서 더 안정적이라고 단정할 수는 없습니다. 직접 연결은 로컬 네트워크에서 회의 서버까지의 경로를 사용합니다. 프록시 연결은 중간에 노드와 추가 구간이 포함되므로, 노드의 혼잡도와 UDP 전달 여부, 목적지까지의 경로가 결과에 영향을 줍니다. 지연 시간이 낮게 표시되는 노드라도 회의 중 패킷 손실이나 순간적인 지연이 발생하면 음성·영상이 불안정할 수 있습니다.
| 관찰할 항목 | 직접 연결을 시험할 때 | 프록시를 시험할 때 |
|---|---|---|
| 음성·영상이 자주 끊김 | 같은 Wi-Fi에서 Shadowrocket 연결을 끈 상태로 회의를 확인합니다. 직접 연결에서도 끊기면 로컬 네트워크나 회사 측 경로를 먼저 살펴봅니다. | 기존에 보유한 노드를 하나 선택하고, 같은 회의 조건에서 재현 여부를 확인합니다. 노드를 바꾸기 전에 현재 설정을 기록합니다. |
| 회의 연결은 되지만 미디어 품질이 낮음 | 회의 앱의 네트워크 진단과 Wi-Fi 신호, 다른 기기의 대역폭 사용을 확인합니다. | UDP가 노드와 네트워크 경로에서 전달되는지 확인합니다. 연결 성공만으로 미디어 경로가 정상이라고 판단하지 않습니다. |
| 로그인이나 채팅만 실패 | 회의 미디어 문제와 분리해 해당 요청에 적용된 규칙과 DNS 결과를 확인합니다. | 관련 요청이 실제로 프록시를 이용하는지 확인합니다. 넓은 도메인 규칙을 추가하면 관계없는 서비스까지 영향을 받을 수 있습니다. |
| 회사 Wi-Fi에서만 실패 | 회사 네트워크의 인증, 방화벽, 프록시 사용 정책을 확인하고 담당 부서에 문의합니다. | 회사 정책이 허용하는 경우에만 시험합니다. 네트워크 제한을 우회하도록 설정을 변경하지 않습니다. |
회의 품질을 확인할 때는 같은 회의 앱, 같은 계정, 같은 Wi-Fi에서 조건을 바꿔 비교하세요. 예를 들어 직접 연결에서 한 차례, 프록시에서 한 차례만 테스트하면 일시적인 네트워크 혼잡을 설정 차이로 오해할 수 있습니다. 각 조건에서 일정 시간 회의를 진행하고, 음성 끊김·화면 정지·재접속 여부와 발생 시각을 기록하면 비교에 도움이 됩니다.
환경별 점검 방향: 집과 모바일 네트워크
집 Wi-Fi
- 먼저 프록시 연결을 끄고 회의 품질을 확인합니다
- 공유기와 기기 사이의 무선 신호, 다른 기기의 대역폭 사용을 살핍니다
- 프록시 사용 전후에 같은 회의 조건을 유지합니다
셀룰러 네트워크
- Wi-Fi와 같은 노드·라우팅 조건으로 비교합니다
- 통신 상태 변화와 데이터 절약 설정을 확인합니다
- 차이가 나면 네트워크별 결과를 따로 기록합니다
한 네트워크에서만 문제가 생기면 노드 설정을 전부 바꾸기보다 해당 네트워크의 경로와 정책부터 확인하세요.
UDP 전달 여부와 네트워크 제한 확인
실시간 음성·영상은 지연과 전송 손실에 민감합니다. 회의 앱이 UDP를 사용할 수 있다고 해도, 앱·회의 서버·네트워크 조건에 따라 실제 요청 경로와 전송 방식은 달라질 수 있습니다. Shadowrocket에 노드가 표시되고 VPN 연결 상태가 켜져 있다는 사실만으로 UDP가 회의 목적지까지 정상 전달된다고 보장되지는 않습니다. 반대로 특정 UDP 요청이 실패해도 모든 회의 기능이 반드시 중단되는 것은 아닙니다. 서비스가 다른 연결 방식으로 재시도할 수 있기 때문입니다.
먼저 집 Wi-Fi에서 회의 앱을 프록시 없이 사용해 기준 상태를 확인하세요. 이후 같은 네트워크에서 Shadowrocket을 켜고 동일한 회의를 다시 시험합니다. 집에서는 정상인데 회사 Wi-Fi에서만 문제가 발생한다면 회사 네트워크의 인증이나 허용 정책이 원인일 수 있습니다. 회사 네트워크 관리자의 안내를 따르고, 제한을 우회하기 위해 임의의 포트나 규칙을 추가하지 마세요. 회의 서비스가 제공하는 네트워크 진단이 있다면 그 결과도 함께 기록합니다.
- 음성만 끊김: 회의 앱의 마이크 권한과 오디오 장치, 네트워크 진단을 확인합니다. 다른 참가자의 음성도 같은 시점에 끊기는지 구분합니다.
- 영상만 멈춤: 카메라 권한과 영상 품질 설정을 살펴보고, 화면 공유나 다른 대용량 전송이 겹치는지 확인합니다.
- 회의 입장이 안 됨: 로그인·초대 링크 요청과 회의 미디어 연결을 구분합니다. 요청 기록에서 어떤 도메인이나 규칙이 적용됐는지 확인합니다.
- 연결이 자주 다시 설정됨: 노드 전환, Wi-Fi와 셀룰러 간 자동 전환, On Demand 조건이 테스트 도중 작동했는지 살펴봅니다.
테스트 도중 노드, DNS, 규칙, Global Routing을 한꺼번에 바꾸면 원인을 구분하기 어렵습니다. 기존 설정을 보존하고 한 번에 한 항목만 변경하세요. 회의에 필요한 연결을 확인할 때는 회의 앱의 진단 화면, Shadowrocket의 요청 기록, 발생 시각을 함께 비교하되, 구독 주소·인증 정보·개인 회의 링크는 외부에 공유하지 마세요.
Config에서 회의 라우팅을 단계별로 시험하기
아래 절차는 앱 이름을 직접 선택해 라우팅하는 기능이 아니라, Config의 규칙과 Global Routing을 이용해 요청 경로를 비교하는 방법입니다. 시작하기 전에 현재 선택된 Config와 Global Routing을 적어 두고, 회의가 끝난 뒤 원래 설정으로 되돌릴 수 있게 하세요. 예시 도메인은 규칙 작성 형식을 설명하기 위한 것이며, 모든 Zoom·Teams 요청을 포함하는 완전한 목록이 아닙니다.
-
기준 상태 기록
Home에서 현재 항목과 연결 상태를 확인하고, Home → Global Routing에 표시된 선택 항목을 기록합니다. Shadowrocket을 끈 상태에서도 같은 회의 문제가 발생하는지 확인해 기준을 만드세요.
-
현재 Config 확인
Config에서 실제 사용 중인 설정 파일과 규칙을 확인합니다. 규칙을 수정하기 전에 원본을 보존하고, 회의 관련 요청에 적용되는 기존 규칙이 있는지 살펴보세요.
-
한 가지 경로 시험
Home → Global Routing에서 기존 규칙을 시험하려면 Config를 선택합니다. 직접 연결 또는 프록시 경로를 비교할 때는 해당 전역 선택이 규칙 결과를 덮을 수 있다는 점을 유의하고, 테스트 후 원래 선택으로 되돌립니다.
-
요청 기록 확인
회의 앱을 사용한 직후 Shadowrocket의 요청 기록에서 관련 요청과 적용된 정책을 확인합니다. 도메인이 보이지 않거나 요청을 확실히 식별할 수 없다면 추측으로 광범위한 규칙을 추가하지 마세요.
-
규칙 변경 후 재시험
확인된 대상에 한해 규칙 하나를 조정하고 같은 회의를 다시 테스트합니다. 결과가 나아지지 않으면 변경을 되돌리고, 다른 조건을 하나씩 확인하세요. 회의가 끝나면 업무 외 트래픽에 영향을 주지 않도록 임시 설정을 복구합니다.
규칙 예시는 다음처럼 작성할 수 있지만, 실제 적용 전에 대상 요청이 맞는지 확인해야 합니다.
[Rule]
DOMAIN-SUFFIX,zoom.us,DIRECT
FINAL,PROXY위 예시는 zoom.us 접미사에 해당하는 요청의 라우팅을 설명하기 위한 것입니다. Zoom 회의의 모든 미디어 요청이 이 도메인만 사용한다고 뜻하지 않으며, 조직에서 별도 도메인이나 정책을 사용할 수도 있습니다. Teams도 마찬가지로 특정 도메인 접미사 하나만으로 모든 로그인·채팅·회의 요청을 포괄한다고 가정하지 마세요. 규칙은 위에서 아래로 평가되므로 더 앞선 규칙이 먼저 일치하면 뒤에 둔 예외가 적용되지 않을 수 있습니다. FINAL은 앞선 규칙과 일치하지 않은 요청을 처리하므로 목록의 위치도 확인하세요.
회의 요청을 직접 연결하도록 바꿔도 회사의 방화벽이나 회의 서비스 정책이 달라지는 것은 아닙니다. 회사에서 승인한 네트워크 경로와 설정을 우선하고, 서비스 접근이나 업무 보안과 관련한 제한은 관리자에게 확인하세요.
결과를 해석하고 원래 설정으로 복구하기
직접 연결에서 안정적이고 프록시에서만 끊긴다면 노드 경로, UDP 전달, 중간 구간의 혼잡 여부를 점검할 근거가 됩니다. 다만 한 번의 회의 결과만으로 특정 노드나 프로토콜의 일반적인 성능을 단정하지 마세요. 반대로 프록시에서만 정상이라면 로컬 네트워크의 목적지 접근이나 경로 차이를 살펴볼 수 있지만, 회사 네트워크 정책과 보안 요구사항을 먼저 확인해야 합니다.
양쪽 조건 모두 불안정하면 Shadowrocket 규칙만 계속 추가하지 말고 Wi-Fi 신호, 공유기 부하, 셀룰러 수신 상태, 회의 앱 진단을 확인하세요. Zoom 또는 Teams에서만 문제가 생기는지, 다른 회의 기능이나 웹 요청도 함께 실패하는지 구분하면 범위를 좁힐 수 있습니다. 설정을 바꾼 시각과 회의 증상을 메모해 두면 같은 테스트를 반복하거나 지원을 요청할 때 유용합니다.
회의 앱만 프록시로 보낼 수 있나요?
앱 이름만으로 모든 트래픽을 분리하는 설정이라고 단정하지 마세요. Config 규칙은 확인 가능한 도메인이나 IP 조건을 기준으로 적용하므로, 요청 기록에서 대상을 식별한 뒤 좁은 범위로 시험해야 합니다.
UDP가 막혀 있으면 회의가 항상 실패하나요?
항상 그렇지는 않습니다. 서비스가 다른 연결 방식으로 재시도할 수 있지만, 품질이나 기능이 달라질 수 있습니다. 회의 앱의 네트워크 진단과 실제 음성·영상 상태를 함께 확인하세요.
설정을 바꾼 뒤 문제가 더 커졌어요.
추가한 규칙과 Global Routing 변경을 되돌리고, 기록해 둔 원래 Config와 선택 항목을 복구하세요. 이후 한 조건씩 다시 시험하고 회사 네트워크라면 관리자 지침을 확인하세요.
판단 기준: 먼저 기준 상태를 확보하고 한 경로씩 비교하세요
회의가 끊기는 문제는 앱 이름만으로 해결할 수 있는 단일 규칙 문제가 아닙니다. 프록시를 끈 기준 상태, 동일 네트워크의 프록시 상태, 실제 요청 기록을 차례로 비교하고, 확인되지 않은 도메인을 추측해 추가하지 않는 것이 안전한 점검 순서입니다.