Zoom·Teams 화상회의가 끊길 때는 서버 지연 시간만 보지 말고 회의 앱의 요청이 어떤 경로로 처리되는지, 선택한 연결이 UDP를 지원하는지, 현재 Wi-Fi나 셀룰러망이 안정적인지도 함께 확인해야 합니다. Shadowrocket은 iPhone·iPad에서 도메인과 IP 등의 규칙을 기준으로 트래픽을 분류하며, 앱 이름을 골라 앱별 터널을 설정하는 방식은 아닙니다. 이미 보유한 연결 정보와 구성을 사용하는 전제로, 회의 서비스에 영향을 주는 규칙을 점검하고 작은 범위에서 검증하는 절차를 설명합니다.
먼저 확인할 원인: 지연 시간보다 경로와 UDP
회의 중 화면이 멈추거나 목소리가 끊기는 현상은 한 가지 설정만으로 설명되지 않습니다. Wi-Fi 신호가 약하거나 통신망이 혼잡하면 프록시 경로와 관계없이 패킷 손실이 늘 수 있습니다. 반대로 웹페이지는 잘 열려도 실시간 음성·영상 연결의 지연이나 손실이 크면 회의 품질은 나빠질 수 있습니다. 따라서 Shadowrocket의 지연 시간 측정 결과가 낮다는 이유만으로 통화도 안정적이라고 단정하지 마세요. 측정 대상과 실제 회의 미디어 경로가 같다고 보장할 수 없습니다.
Zoom과 Teams는 로그인, 회의 제어, 음성·영상 미디어 등 여러 연결을 사용할 수 있습니다. 실시간 미디어에는 UDP가 사용될 수 있으며, 네트워크나 연결 경로에서 UDP가 원활하지 않으면 서비스가 다른 경로로 전환하거나 연결 품질이 저하될 수 있습니다. 프로토콜이 UDP를 지원하는지 확인하는 것과 실제 회의 트래픽이 UDP로 전달되는지는 별개의 문제입니다. 서비스 측 정책, 서버 설정, 네트워크 제한도 결과에 영향을 줍니다.
회의가 시작되기 전에 같은 장소와 같은 네트워크에서 짧게 테스트해 기준을 만들어 두세요. 먼저 Shadowrocket을 끈 상태에서 통화를 확인하고, 이어서 켠 상태에서도 같은 회의 앱과 네트워크로 비교합니다. 한 번에 Wi-Fi, 서버, 라우팅 규칙을 모두 바꾸면 무엇이 개선이나 악화의 원인이었는지 판단하기 어렵습니다.
앱별 분할 터널링과 도메인 규칙의 차이
‘Zoom만 프록시로 보내기’처럼 앱 이름을 기준으로 경로를 나누고 싶을 수 있지만, Shadowrocket의 일반적인 Config 규칙은 앱 이름이 아니라 요청에서 확인되는 도메인, IP 등의 조건으로 트래픽을 분류합니다. 같은 앱도 로그인과 회의 미디어에 서로 다른 호스트를 사용할 수 있고, 서비스가 주소를 바꾸거나 CDN을 이용할 수도 있습니다. 그래서 한두 개의 도메인 규칙만 추가해도 Zoom 또는 Teams 전체 트래픽이 모두 같은 경로를 이용한다고 보장할 수 없습니다.
실제 서비스 도메인을 임의로 추측해 광범위한 규칙을 추가하기보다는, 이용 중인 조직의 네트워크 담당자가 제공하는 요구사항과 Shadowrocket에서 확인 가능한 연결 정보를 기준으로 범위를 좁히세요. 업무 계정이나 회의 내용이 오가는 트래픽을 신뢰할 수 없는 경로로 보내지 마세요. 회사가 지정한 VPN이나 보안 정책이 있다면 이를 우선하고, Shadowrocket 설정이 조직의 접속 요건을 대신한다고 가정하지 않아야 합니다.
| 설정 방식 | 동작 | 확인할 점 |
|---|---|---|
Config 규칙 |
구성 파일의 규칙에 따라 요청을 분류 | 서비스가 사용하는 여러 도메인과 IP가 규칙에 포함되는지 확인 |
Proxy |
전체 라우팅을 프록시 경로로 시험 | 규칙 문제를 구분하는 임시 점검에만 사용하고 결과를 확인한 뒤 원래 모드로 복귀 |
Direct |
직접 연결 경로를 기준으로 확인 | 조직의 보안 정책과 서비스 접속 요건에 맞는지 확인 |
회의 앱이 프록시를 거쳐야 하는지, 직접 연결해야 하는지는 모든 사용자에게 같은 답이 있는 설정이 아닙니다. 현재 네트워크에서 회사 정책과 서비스 요구사항을 확인한 뒤 결정하세요. Home의 연결 스위치가 켜져 있다는 사실만으로 회의 앱의 모든 요청이 프록시를 이용한다는 뜻은 아닙니다.
규칙 확인 전 준비: 구성을 보존하고 기준 상태 기록
규칙을 바꾸기 전에 현재 사용 중인 구성과 Home의 선택 서버를 확인하세요. 서버 연결 자체가 불안정한 상태라면 도메인 규칙을 추가해도 통화 문제가 해결되지 않습니다. 반대로 서버 연결은 정상인데 회의 서비스만 실패한다면 라우팅 모드와 규칙을 별도로 살펴볼 이유가 있습니다. 구성 수정 전에 복원할 수 있도록 사본을 보관하고, 원래의 FINAL 정책을 무조건 DIRECT나 프록시 정책으로 바꾸지 마세요.
아래 규칙은 문법을 보여 주기 위한 예시이며, 실제 Zoom·Teams 도메인이 아닙니다. meeting.example.com을 실제 서비스 도메인이라고 간주하거나 그대로 연결 설정에 적용하지 마세요. 정책 이름인 PROXY도 선택한 구성에 실제로 존재하는 정책인지 확인해야 합니다.
[Rule]
DOMAIN-SUFFIX,meeting.example.com,PROXY
FINAL,DIRECT
DOMAIN-SUFFIX는 지정한 도메인과 하위 도메인에 매칭됩니다. 도메인 규칙은 앱 자체를 식별하지 않으며, 해당 도메인으로 향하는 다른 앱의 요청에도 적용될 수 있습니다. 구성에 이미 더 앞선 규칙이 있으면 새 규칙에 도달하기 전에 요청이 분류될 수도 있습니다. 따라서 규칙을 추가할 때는 기존 항목의 순서, 정책 이름, 최종 규칙을 함께 확인해야 합니다.
앱 이름을 기준으로 분할 터널링한다고 가정하지 마세요. 도메인 규칙은 해당 도메인으로 향하는 요청에 적용되므로, 실제로 어떤 요청이 매칭되는지와 조직의 보안 정책을 함께 확인해야 합니다.
단계별 회의 경로 테스트
아래 절차는 설정을 한 번에 크게 바꾸지 않고 비교하기 위한 것입니다. 테스트가 끝나면 임시로 바꾼 라우팅 모드나 규칙을 원래 상태로 되돌리고, 실제 업무 통화 전에 다시 확인하세요. 회의의 참가자, 영상 설정, 네트워크 상태가 크게 다르면 비교 결과도 달라질 수 있습니다.
-
기준 통화 확인
Shadowrocket 연결 상태와 현재 네트워크를 기록한 뒤 짧은 테스트 통화를 합니다. 음성 끊김, 영상 멈춤, 재접속 여부를 구분해 메모하고, 가능하면 회의 앱의 자체 연결 진단도 함께 확인하세요.
-
연결 정보 점검
Home에서 선택된 SERVER 항목을 확인하고, 사용 중인 연결 정보가 유효한지 점검하세요. 지연 시간 결과만 보지 말고 연결 실패나 시간 초과가 반복되는지도 살펴봅니다. 이미 보유한 서비스와 설정만 사용하세요.
-
모드 확인
Home → Global Routing에서 현재 모드를 확인하세요. 규칙 기반 테스트라면 적용할 구성이 선택되어 있는지 확인한 뒤 Config를 사용합니다. Proxy나 Direct로 임시 비교했다면 결과를 기록하고 기존 모드로 돌아가세요.
-
규칙 범위 확인
Config에서 실제 적용 중인 규칙과 순서를 살펴보세요. 회의 서비스 관련 도메인을 확인할 근거가 있을 때만 필요한 범위로 추가하고, 앞선 포괄 규칙이나 기존 FINAL 처리와 충돌하지 않는지 확인합니다.
-
한 조건씩 비교
같은 네트워크와 비슷한 통화 조건을 유지한 채 변경 전후를 비교하세요. Wi-Fi와 셀룰러 전환, 서버 변경, 규칙 수정은 한 번에 하나씩 진행합니다. UDP 동작은 구성과 네트워크에 따라 달라질 수 있으므로 앱의 실제 통화 결과로 확인하세요.
Home에서 연결됨으로 보이더라도 회의 서비스와의 연결까지 보장되는 것은 아닙니다. Connectivity Test도 진단의 한 자료로 사용하되, 테스트 결과를 Zoom·Teams의 실제 미디어 품질과 동일시하지 마세요. 회의 전 짧은 시험 통화에서 음성과 영상을 따로 확인하고, 문제가 재현되는 시점과 네트워크 종류를 기록하면 원인을 좁히는 데 도움이 됩니다.
끊김 상황별 점검: Wi-Fi·셀룰러·라우팅 분리
집에서만 끊긴다면 먼저 공유기와 Wi-Fi 신호, 다른 기기의 대역폭 사용을 확인하세요. 공유기 가까이에서 시험하거나, 같은 기기에서 다른 네트워크를 사용해 결과를 비교할 수 있습니다. 셀룰러에서만 문제가 생긴다면 신호 세기뿐 아니라 이동 중 네트워크 전환이나 통신사 측 제한도 영향을 줄 수 있습니다. 앱 설정만 계속 바꾸기 전에 네트워크별 결과를 기록하세요.
회의 제어 화면은 열리지만 음성이 끊기거나 영상이 멈춘다면 로그인 경로와 미디어 연결 경로가 다를 가능성을 고려해야 합니다. 모든 서비스 도메인을 임의로 프록시 처리하거나, 광범위한 IP 범위를 추가해 문제를 덮으려 하지 마세요. 반대로 회의 앱 전체가 로그인되지 않는다면 잘못된 규칙 순서, 사용 불가능한 정책, 선택된 Global Routing 모드부터 확인하세요.
지연 시간은 낮은데 통화가 끊겨요
지연 시간 측정 대상이 회의 미디어 서버와 같다고 볼 수 없습니다. 같은 네트워크에서 앱 자체의 통화 진단과 실제 음성·영상 상태를 비교하고, 패킷 손실이나 네트워크 전환이 있는지 확인하세요.
회의 화면만 열리고 소리가 안 나요
제어 연결과 미디어 연결이 서로 다른 경로를 사용할 수 있습니다. Config 선택 상태와 관련 규칙 순서를 확인하고, 조직에서 지정한 연결 요건이 있는지 담당자에게 확인하세요.
Wi-Fi에서는 되고 셀룰러에서는 실패해요
셀룰러 신호와 통신망 상태를 먼저 확인한 뒤 같은 설정으로 재시험하세요. On Demand 설정이 연결 상태를 바꾸는지 살펴보고, 여러 규칙을 동시에 변경하지 마세요.
결론: 앱 이름이 아니라 실제 경로를 검증하세요
화상회의 안정성은 서버 지연 시간 하나로 판단할 수 없습니다. 규칙이 적용되는 모드인지, UDP를 포함한 실제 연결이 네트워크에서 동작하는지, 회의 서비스의 요청이 의도한 경로로 분류되는지를 각각 확인하세요. 변경은 작은 범위로 하고, 업무용 보안 정책과 기존 구성을 우선 보존하는 것이 안전합니다.