Discord 음성 끊김? Clash TUN·UDP 점검 (2026)

왜 글은 되는데 음성만 불안정해 보일까

Discord의 채널 목록·텍스트·이미지는 대체로 TCP(HTTPS) 위에서 동작합니다. 규칙이 대략 맞으면 “쓸 만하다”고 느껴집니다. 반면 음성 통화는 실시간 미디어를 위해 UDP를 많이 사용하고, 지연 스파이크·초 단위 끊김·한쪽 소리만 사라짐 같은 보고는 UDP 세션의 품질이나 출구 불일치와 잘 맞습니다. 같은 시각에 글은 정상이라고 해서 “서버가 완전히 죽었다”고 결론내리기보다, UDP만 기대한 프록시 경로를 타지 않았거나 노드가 UDP 릴레이에 약하거나 TCP와 UDP에 서로 다른 규칙·DNS 답이 걸렸는지를 먼저 의심하는 편이 낫습니다.

또 한 가지 오해는 “시스템 프록시를 켰으니 Discord 전부가 Clash를 탄다”는 가정입니다. 데스크톱 앱은 자체 스택을 쓰거나 QUIC·HTTP/3 경로가 갈라질 수 있어, TUN 없이 프록시 설정만으로는 로그에 같은 앱 두 가지 네트워크 행동이 찍히기도 합니다. 따라서 첫 단계는 감으로 노드만 바꾸는 것이 아니라, 연결·로그에 무엇이 찍히는지를 기준으로 가설을 좁히는 것입니다.

Discord 음성 뒤의 UDP·WebRTC·QUIC

세부 RFC를 외울 필요는 없지만, 모델은 분명히 갖추는 것이 좋습니다. 로그인·REST·웹 소켓에 가까운 흐름과 보이스 RTP에 가까운 UDP는 OS 안에서도 다른 소켓으로 보일 수 있습니다. Clash 계열이 이 둘을 한 규칙 표로 엮으려면 Rule 모드와 더불어 패킷이 실제로 코어에 들어오는 경로가 맞아야 하며, TUN은 종종 시스템 프록시보다 넓은 범위를 덮습니다. 브라우저가 HTTP/3(QUIC)을 쓰면 로그에 UDP 443 형태가 섞일 수 있어, Sniffer 없이 도메인 규칙이 IP로만 맞는 순간 “가끔만 된다”는 착시가 납니다. 그래서 이 글은 도메인 목록만 나열하지 않고, 아래에서 규칙 순서와 스니퍼를 같이 언급합니다.

시스템 프록시와 TUN: 무엇이 음성까지 덮는가

시스템 프록시(System proxy)는 브라우저에는 잘 먹히지만, VoIP·게임 계열 UDP가 전부 따라오지는 않습니다. TUN 모드는 가상 인터페이스로 라우팅에 더 가깝게 개입해, “왜 이 프로세스는 프록시를 모르지?” 하는 트래픽까지 규칙 표에 태우기 쉽습니다. Windows에서 처음 세팅할 때는 Clash Verge Rev Windows 설치·초기 설정을 먼저 맞춘 뒤, Clash Verge Rev TUN 모드 가이드에서 가상 어댑터·권한·방화벽 예외를 확인하는 순서가 안전합니다. Linux 데스크톱에서는 systemd와 함께 쓰는 흐름이 Linux·Mihomo·TUN 글과 겹칩니다.

실무 팁: 점검할 때 변수는 한 번에 하나만 바꿉니다. 노드를 고정한 채 시스템 프록시만과 TUN 켠 상태를 번갈아 같은 음성 테스트로 비교하면 로그 차이가 선명해집니다.

1연결 로그에서 UDP와 정책 이름 찾기

Mihomo(Clash Meta) GUI의 연결·로그 화면을 켠 뒤 음성 채널에 들어가 보세요. 공인 IP로 향하는 UDP가 충분히 보이나요? 각 줄이 어떤 정책 그룹·아웃바운드로 기록되는지 확인합니다. Discord 관련 TCP만 잔뜩이고 UDP가 거의 없다면, 음성이 아예 기대한 터널에 안 올라온 것일 수 있습니다. UDP가 보이는데도 정책이 생각과 다르면 rules 상단의 넓은 RULE-SET·GEOIP가 먼저 매칭됐는지부터 봅니다. 앞쪽 규칙 한 줄이 결정을 내리면, 아래에 적어 둔 discord 전용 줄은 영원히 실행되지 않는 경우가 많습니다.

2Discord를 규칙에 넣고 UDP가 따라오게 하기

실제 호스트명은 서비스 정책에 따라 바뀔 수 있으니, 아래는 출발점일 뿐이며 최종 확정은 로그에 나온 이름으로 합니다. 흔히 discord.com, discordapp.com, discord.gg와 CDN·보이스 리전 IP 대역이 함께 등장합니다. PROXY 자리에는 구독에 정의된 실제 그룹 이름을 넣고, YAML 예시는 주석을 영어로 두었습니다.

# Example — replace PROXY; verify UDP/TCP hits in client logs
rules:
  - DOMAIN-SUFFIX,discord.com,PROXY
  - DOMAIN-SUFFIX,discordapp.com,PROXY
  - DOMAIN-SUFFIX,discord.gg,PROXY
  # Log-observed CDN or voice hosts go here
  - MATCH,DIRECT

여기서 PROXY는 “표시상 프록시”가 아니라 UDP까지 전달 가능한 노드·그룹이어야 합니다. 릴레이 품질이 나쁘면 로그상으로는 맞아도 체감은 계속 끊깁니다. 이는 노드 역량 문제이며, 도메인 줄을 몇 줄 더 얹는다고 해결되지 않는 클래스입니다.

규칙 우선순위: GEOIP·대형 RULE-SET이 먼저 끝내지 않게

Clash는 위에서 아래로 첫 매칭이 곧 결론입니다. Discord 전용 줄을 맨 아래에 두고 위에는 느슨한 GEOIP·국내 직통·대형 리스트만 두었다면, TCP는 우연히 통과해도 UDP만 다른 출구로 빠지는 조합이 나올 수 있습니다. 조정할 때는 Discord 관련 DOMAIN·DOMAIN-SUFFIX를 이해 가능한 상단 구역으로 올리되, 사설망·로컬 예외는 그대로 유지합니다. 한 번 바꿀 때마다 로그를 다시 대조하세요.

Sniffer와 QUIC: 도메인 규칙이 “이름을 볼 수 있을 때” 제대로 작동한다

로그에 IP만 찍히면 DOMAIN·GEOSITE류 규칙이 빗나갈 수 있습니다. Clash Meta의 Sniffer는 TLS·QUIC 등에서 호스트를 복원해 매칭을 안정화합니다. 개념과 단계는 Clash Meta Sniffer: HTTPS 도메인 분할 구성을 보고, 본 절의 UDP 관찰과 같은 세션에서 함께 검증하는 것이 좋습니다.

3relay 이중 홉을 쓸 때 UDP는 한 층 더 민감하다

proxy-groups에서 type: relay로 두 홉을 이으면 TCP도 까다롭지만, UDP는 한 홉이 UDP를 제대로 못 받거나 지연이 배로 느껴지는 경우가 있습니다. 체인을 켜 두었다면 relay 체인·점검 순서 글의 UDP·QUIC 항목을 음성 테스트와 함께 대조하세요.

DNS·FakeIP·TUN: 해석과 실연결이 따로 노는 문제

FakeIP, redir-host, 업스트림 DNS가 엇갈리면 “규칙을 썼는데 안 먹는다”는 느낌이 납니다. 음성에서는 리전 전환·RTC 후보 수집 타이밍에 민감해, 가끔 채널 입장만 실패하거나 보이스 서버가 바뀔 때 멈춘 것처럼 보이기도 합니다. 기본선은 Meta 코어 DNS 유출 방지 가이드의 흐름으로 질의 경로를 한 번에 정돈한 뒤, 규칙 적중 → DNS 화면 → 실제 UDP 출구를 서로 맞춰 보는 것입니다.

주의: PC에 다른 VPN·사내 보안 에이전트·공유기 차단이 동시에 켜져 있으면 라우팅과 DNS가 이중으로 가로채져 지연이 폭증합니다. 단일 경로로 줄인 뒤 음성을 다시 재현해 보세요.

권장 점검 순서(체크리스트)

UDP 출구: 같은 노드를 고정하고 TUN을 켠 뒤 음성을 재생·송신해 보고, 로그에 기대만큼 UDP가 뜨는지·같은 정책인지 확인합니다.
규칙 순서: 넓은 규칙보다 앞에 DOMAIN-SUFFIX 등 Discord 후보를 두었는지, HTTPS·QUIC에는 Sniffer가 필요한지 확인합니다.
DNS: FakeIP·DoH·nameserver-policy가 규칙 전제와 모순되지 않는지, TUN과 dns-hijack 설정이 합치하는지 봅니다.
노드·체인: 앞 세 단계가 정리된 뒤에 다른 출구·단일 홉으로 바꿔 비교합니다(relay 사용 시 relay 글의 UDP 절을 병행).

네 가지를 거친 뒤에도 개선이 없으면 막대·헤드셋·Discord 자체 장애·대역폭 등 비프록시 요인을 좁히면 됩니다. 다만 Clash 사용자 문맥에서 보이는 “항상 음성만” 패턴은 위 순서로 상당 부분 정리됩니다.

같은 UDP 문제를 다루는 인근 글

같은 Wi-Fi에서 휴대폰으로 mixed-port를 공유하는 시나리오는 UDP가 LAN·방화벽에 어떻게 노출되는지 LAN 공유·mixed-port·방화벽 글과 연결됩니다. 전체 분기 지도는 문서·설정 허브 목차와도 맞물립니다.

오픈소스 정보와 설치 패키지

Mihomo와 GUI 포크들의 라이선스·이슈는 GitHub에서 추적할 수 있지만, 설치 파일을 받는 주 경로로는 이 사이트 Clash 다운로드 페이지를 권장합니다. 소스는 신뢰 확인용으로 두고, 일상 업데이트는 공식 허브에 맞추면 혼선이 줄어듭니다.

맺음말

Discord 음성 이슈는 대개 UDP·WebRTC 경로와 Clash의 규칙·TUN 적용 범위가 어긋난 자리에서 시작합니다. 텍스트가 되는 것을 “프록시는 이미 OK”로 단정하면 시간이 낭비됩니다. 노드를 무작정 바꾸기보다 로그의 UDP → 규칙 적중 → DNS·Sniffer → 노드 역량 순으로 좁히면, 프록시 밖으로 새는 트래픽인지 위에서 규칙을 잡아먹힌 것인지 출구가 음성에 부적합한 것인지 구분하기 쉬워집니다. 같은 관측 루틴은 다른 VoIP·화상 회의에도 이식할 수 있습니다.

여러 대안 중에서도 Clash Meta·Mihomo는 정책 그룹 이름과 연결 로그를 한 화면에서 대응시키기 좋아, 감각적 끊김을 관측 가능한 사실로 바꾸기에 유리합니다. 음성과 우회를 같이 쓰려면 한번 TUN과 규칙 표를 읽기 쉬운 형태로 정리해 두는 편이 낫습니다.

→ Clash를 무료로 다운로드하고, Discord 음성에 맞춰 UDP와 TUN 경로를 확인해 보세요

Discord 음성이 끊길 때: Clash TUN·UDP·규칙 단계별 점검 (2026)