Clash에서 Discord 음성만 끊길 때: discord.gg·WebRTC·UDP를 5단계로 분리 점검하기 (2026)

이 증상이 Clash와 만날 때 흔한 패턴

서버 목록·텍스트·스티커·일부 임베드는 정상인데, 음성에 들어가면 연결 중이 길어지거나 몇 초마다 끊깁니다. 또는 음성은 되는데 RTC 연결 지역이 실제 노드와 다른 대륙으로 잡혀 지연이 커집니다. 이때 브라우저에서 Discord를 쓰는지, 데스크톱·모바일 앱을 쓰는지에 따라 프록시 인지 방식도 달라지므로, 재현 환경을 먼저 메모해 두는 것이 좋습니다.

Clash는 규칙으로 도메인 이름을 아웃바운드에 매핑하지만, 음성은 연결 수립 뒤 IP·UDP로 이어지는 구간이 길고, 일부는 대칭형 NAT나 STUN 타이밍에 민감합니다. «전역 프록시인데 왜 음성만 이상하지?»라고 느낄 때는 전역이라도 UDP가 OS에서 직행하는 케이스를 의심하는 것이 첫걸음입니다.

채팅은 되는데 음성만 깨지는 이유: TCP와 UDP·WebRTC

Discord의 텍스트·REST 성격의 요청은 대부분 HTTPS로 잘 올라갑니다. 반면 음성 통화는 WebRTC를 통해 미디어 경로를 잡고, 그 과정에서 UDP를 쓰는 비중이 큽니다. 프록시 클라이언트가 시스템 프록시만 설정한 상태라면, HTTP(S)를 따르는 트래픽과 UDP 음성의 경로가 갈라질 수 있습니다.

또한 음성은 지속적인 패킷 손실·지터에 민감해, 같은 노드라도 TCP 다운로드 테스트와 체감이 다릅니다. 그래서 «속도 테스트는 괜찮은데 음성만 나쁘다»는 말이 자주 나옵니다. 아래 단계는 이런 구조적 차이를 전제로, Clash 설정에서 무엇을 순서대로 확인할지를 압축한 것입니다.

1단계: 규칙 모드·로그로 Discord 트래픽의 출구 확인

먼저 Clash가 Rule 모드인지, Global인지, 혹은 특정 앱만 예외인지 확인합니다. Rule 모드라면 코어 로그(또는 GUI의 연결 패널)에서 discord 문자열이 포함된 호스트가 어느 정책 그룹으로 나갔는지 봅니다. 여기서 기대한 그룹이 아니라면, 위쪽 규칙에 GEOIP나 광범위한 MATCH가 먼저 걸려 직행(DIRECT)으로 새는지부터 점검합니다.

같은 시각에 브라우저와 데스크톱 앱을 동시에 켜 두면, 서로 다른 프로세스가 서로 다른 인터페이스를 탈 수 있습니다. 테스트할 때는 한 가지 클라이언트만 켜고, 음성 채널 입장 직후 로그를 1~2분만 캡처해 보면 재현이 쉬워집니다. 구독 프로필이 오래됐다면 구독 자동 갱신이 정상인지도 함께 확인해 주세요. 규칙 세트 자체가 비어 있으면 아무리 클라이언트를 바꿔도 같은 벽에 부딪힙니다.

2단계: discord.gg와 Discord 관련 접미사를 규칙으로 묶기

대표적으로 discord.gg 초대 링크, discord.com, 예전에 쓰이던 discordapp.com, 일부 기능에 등장하는 discordsays.com 등이 자주 언급됩니다. 실제 환경에서는 클라이언트 버전·기능에 따라 추가 호스트가 로그에 찍히므로, DOMAIN-SUFFIX로 묶을 때는 코어 로그에 보인 문자열을 우선으로 반영하는 편이 안전합니다.

규칙 순서는 위에서 아래로 첫 매칭만 적용됩니다. Discord 전용 그룹을 두었다면, 그보다 위에 있는 GEOIP,CN,DIRECT 같은 줄이 음성과 무관한 호스트까지 직행으로 보내지 않는지 확인합니다. 반대로 광고 차단·추가 Rule Provider를 쓰는 경우, 차단 목록에 미디어 관련 호스트가 들어 있으면 «채팅만 되고 음성만 안 된다»는 형태로 나타나기도 합니다.

rules:
  # Example: route Discord domains to a dedicated group (adjust names to your profile)
  - DOMAIN-SUFFIX,discord.gg,DISCORD
  - DOMAIN-SUFFIX,discord.com,DISCORD
  - DOMAIN-SUFFIX,discordapp.com,DISCORD
  - DOMAIN-SUFFIX,discordsays.com,DISCORD

DISCORD는 proxy-groups에 정의된 이름이어야 하며, 오타는 해당 줄이 통째로 무시되거나 기동 오류로 이어질 수 있습니다. 정책 그룹·Rule Provider 전반은 YAML 규칙 분기에서 다룬 패턴과 맞추면 유지 보수가 수월합니다.

3단계: UDP와 TUN — 음성이 프록시를 실제로 타는지

많은 사용자가 «전역이라서 다 된다»고 가정하지만, 시스템 프록시만 켠 상태에서는 UDP가 Clash까지 오지 않고 원래 회선으로 나가는 경우가 있습니다. 음성이 그런 경로로 나가면, 채팅은 프록시 노드 근처로 잘 가고 음성만 다른 NAT·지역으로 퍼지는 비대칭이 생깁니다.

이때 시도해 볼 것은 TUN 모드(가상 NIC를 통한 투명 프록시)입니다. OS 라우팅 계층에서 트래픽을 끌어오기 때문에, 애플리케이션이 프록시를 «모른다»는 전제에 더 가깝습니다. Windows·macOS에서 TUN을 켤 때의 권한·가상 어댑터·다른 VPN과의 충돌은 TUN·시스템 프록시 가이드에 정리해 두었습니다. TUN을 켠 뒤에도 UDP가 의심되면, 사용 중인 클라이언트가 mihomo(Clash Meta) 계열인지, UDP relay 관련 옵션이 프로필에 있는지 제조사 문서를 함께 보는 것이 좋습니다.

4단계: DNS enhanced-mode·fake-ip와 음성 리전

Clash의 DNS 섹션에서 fake-ip를 쓰면, 애플리케이션이 받아 보는 주소와 실제 백엔드 연결이 어플리케이션별로 다르게 해석될 수 있습니다. WebRTC는 후보 수집·체크 순서에 민감해서, 텍스트만 쓸 때는 문제없던 설정이 음성에서만 간헐 끊김으로 드러나기도 합니다.

대응으로는 (1) Discord 관련 도메인을 fake-ip-filter에 넣어 실제 IP를 쓰게 하거나, (2) redir-host 모드와의 차이를 비교하거나, (3) 운영체제 DNS·DoH·라우터 DNS가 이중으로 겹치지 않게 단순화하는 방법이 있습니다. 내부망·로컬 이름과의 관계는 fake-ip vs redir-host 가이드에서 다룬 것과 연결됩니다. 음성 리전이 이상하게 잡힐 때는 노드 위치뿐 아니라 DNS가 어느 국가의 resolver를 쓰는지도 함께 의심해 보세요.

5단계: 노드 품질·대칭 NAT·이중 VPN

규칙과 TUN을 맞춰도 음성 품질이 나쁘다면, 이번에는 아웃바운드 자체를 의심합니다. 지연 변동이 큰 노드·혼잡한 공유 IP·UDP 처리에 취약한 중계는 음성에 바로 드러납니다. Discord 전용 정책 그룹을 두었다면 그 안에서만 노드를 바꿔 A/B 비교하는 것이 원인 분리에 유리합니다.

집 공유기 뒤에서 대칭형 NAT가 강하면 WebRTC 후보가 제한되어 음성이 불안정해질 수 있습니다. 이 경우 Clash만의 문제가 아니라 네트워크 전체의 이슈일 수 있어, 같은 기기에서 Clash를 잠시 끄고 테스트하거나, 다른 회선·테더링으로만 음성을 비교해 보는 것도 방법입니다. 또한 상위에 다른 상용 VPN이 전체 터널로 올라와 있으면 라우팅이 겹쳐 Clash가 아무리 규칙을 맞춰도 패킷이 싸우기 쉽습니다. 업무용 전체 터널 VPN과의 공존은 TUN 가이드의 «다른 VPN과의 공존» 절과 같은 맥락입니다.

증상별로 빠르게 짚는 표

마무리

Clash로 Discord를 쓸 때 음성만 불안정하다면, discord.gg 한 줄을 추가하는 것에서 끝나지 않고, TCP로 잘 되는 경로와 UDP·WebRTC가 실제로 타는 경로를 나눠 생각해야 합니다. 규칙으로 호스트를 묶고, TUN으로 투명 프록시 범위를 맞추고, DNS 모드를 의심한 뒤, 마지막에 노드 품질을 보는 순서가 현장에서 통하는 편입니다. 반복 설정이 부담스럽다면, 검증된 클라이언트 빌드를 고정해 두고 프로필만 갱신하는 운영이 스트레스를 줄여 줍니다.

ClashNote 다운로드 페이지에서는 여러 Clash 계열 클라이언트를 한곳에서 비교하며 설치할 수 있고, 무료로 배포되는 프로그램과 구독 링크를 프로필에 넣는 흐름까지 같은 맥락으로 정리해 두었습니다. 규칙 전반이 궁금하면 기술 칼럼의 YAML·DNS·TUN 글을 이어서 읽어 보세요.