Discord 음성 끊김·RTC 불안? Clash Windows 프로세스·UDP

1. 어떤 증상부터 의심할까

Discord 음성에서 흔한 불편은 (1) 상대 목소리가 잠깐씩 끊기거나 로봇처럼 들리는 것, (2) 채널 입장 후 한동안 음성 연결 중·RTC 연결 중 문구가 사라지지 않는 것, (3) 화면 공유·게임 오버레이와 함께 쓸 때만 악화되는 것입니다. 서버 장애나 지역 혼잡도 원인이 될 수 있지만, 본인 PC에서만 반복된다면 로컬 방화벽·다른 VPN·그리고 Clash의 규칙·모드부터 의심하는 것이 합리적입니다.

특히 «웹사이트는 빠른데 Discord 음성만 이상하다»면 HTTP 위주로 생각하기 쉬운 시스템 프록시만으로는 설명이 안 되는 경우가 많습니다. 음성은 종종 UDP 기반 실시간 경로를 타고, 실행 파일 단위로 정책을 나누지 않으면 브라우저와 다른 출구·다른 NAT 동작을 겪을 수 있습니다. 아래에서는 그 가정을 전제로 단계를 정리합니다.

팁: 문제를 재현할 때는 Discord를 완전히 종료한 뒤 Clash에서 연결 로그를 켜고, 다시 음성 채널에 들어가며 몇 분간 어떤 프로세스·프로토콜이 찍히는지 관찰하면 원인 분리가 빨라집니다.

2. Discord 트래픽이 Clash와 엮일 때

데스크톱 앱은 보통 discord.exe로 표시되며, 업데이트·CDN·음성·핑 측정 등 목적별로 호스트와 포트가 갈립니다. 텍스트·이미지는 TCP 위주로 잘 보이더라도, 음성은 지연에 민감한 흐름이라 패킷이 우회 경로에서 버려지거나, 노드가 UDP를 제대로 중계하지 못하면 체감이 바로 나빠집니다. 또한 규칙 세트가 특정 지역 CDN만 직접 연결로 보내고 음성 관련 구간은 다른 그룹으로 보내는 식이면, 한쪽만 불안정해질 수 있습니다.

본문은 특정 노드 판매나 Discord 정책을 우회하는 방법을 다루지 않습니다. 대신 Windows에서 프로세스 분류와 UDP 전달을 어떻게 검증할지, 그리고 앱 내 음성 품질 설정을 어디까지 손볼 수 있는지에 집중합니다. 공통 문법·모드 전환은 설정 가이드와 입문 튜토리얼을 함께 보면 이해가 빨라집니다.

3. 시스템 프록시만으로는 부족한 이유

Windows의 «프록시 사용»은 많은 앱에 자동으로 전파되지 않으며, 전파되더라도 주로 HTTP(S) 계열에 치우칩니다. Discord 데스크톱은 그런 설정을 일부 무시하거나, 음성 경로만 별도로 나가는 경우가 있어 «시스템 프록시 켰는데 음성만 이상하다»는 말이 반복됩니다. Clash에서는 TUN으로 OS 레벨에서 트래픽을 가로채거나, 코어가 지원하는 프로세스 이름 조건으로 discord.exe만 특정 프록시 그룹에 넣는 방식이 실무에서 자주 쓰입니다.

도메인만으로 discord.com류를 묶는 접근도 있지만, 실제 연결 호스트는 빌드·지역·기능에 따라 달라지고 음성은 IP 단위 동작에 가깝게 보이기도 합니다. 그래서 도메인 규칙과 프로세스 규칙을 함께 쓰면 «호스트명이 바뀌어도 같은 앱은 같은 출구»라는 안정성을 기대하기 쉽습니다. 다만 프로세스 매칭은 OS·클라이언트 버전에 따라 동작 차이가 있으므로, 반드시 로그로 매칭 여부를 확인해야 합니다.

4. 프로세스(Process) 분류로 discord.exe 고정하기

프로세스 분류는 연결이 어느 실행 파일에서 왔는지 식별될 때, 그 트래픽만 원하는 proxy-groups 항목으로 보내는 방식입니다. 브라우저로 Discord 웹을 볼 때와 데스크톱 앱 음성을 쓸 때를 서로 다른 정책으로 나누고 싶다면, 브라우저 프로세스와 discord.exe를 각각 다른 줄에 매핑할 수 있습니다. 이렇게 하면 텍스트·이미지는 가벼운 노드, 음성은 지연·UDP 품질이 검증된 노드로 보내는 식의 실험이 가능합니다.

규칙은 위에서 아래로 첫 매칭이 적용되므로, 구독으로 받은 대형 규칙 묶음보다 개인용 Discord 줄을 더 위에 두지 않으면 의도대로 동작하지 않습니다. MATCH나 광범위한 직접 연결 줄이 위에 있으면 아래의 프로세스 전용 규칙은 실행되지 않습니다. 사용 중인 GUI가 Verge 계열인지 for Windows 계열인지에 따라 편집 화면이 다르므로, 클라이언트 비교 글에서 편집 흐름을 익혀 두면 재시도 속도가 빨라집니다.

보안 측면

프로세스 이름만 보고 정책을 거는 것은 편리하지만, 악성 프로그램이 이름을 흉내 낼 수 있으므로 실행 파일 경로가 공식 설치본인지 항상 확인하세요. 본문은 공식 Discord 클라이언트와 정당한 이용을 전제로 합니다.

5. UDP: 음성 품질과 직결되는 부분

실시간 음성은 TCP만으로 끝나지 않고 UDP를 쓰는 구간이 많습니다. 프록시 스택이 UDP를 떨어뜨리거나, 노드 측에서 UDP가 막혀 있으면 «핑은 낮아 보이는데 말소리만 끊긴다» 같은 증상이 나올 수 있습니다. Clash 계열에서 UDP 지원은 코어 설정·선택한 프로토콜·TUN 사용 여부와 맞물리므로, «웹만 잘 된다»로 음성 문제를 판단하면 오판하기 쉽습니다.

노드를 바꿔도 동일하면 해당 노드가 UDP를 안정적으로 중계하지 않을 가능성을 의심합니다. 반대로 불필요한 전역 UDP 터널은 다른 앱의 정상 동작을 해칠 수 있어, 프로세스 분류로 discord.exe에만 범위를 좁히는 편이 안전합니다. Windows 방화벽에서 Clash·관련 어댑터에 대한 아웃바운드가 막혀 있지 않은지도 함께 확인하세요.

주의: 회사·학교 등에서 프록시·우회 사용이 금지된 네트워크라면, 기술적으로 가능하더라도 정책을 우선해야 합니다. 본문은 개인 기기·허용된 환경에서의 자가 점검을 전제로 합니다.

6. TUN 모드와의 조합

TUN을 켜면 가상 어댑터를 통해 앱이 프록시를 직접 알지 못해도 트래픽이 코어를 거칠 수 있어, 시스템 프록시를 잘 따르지 않는 데스크톱 앱을 다룰 때 유용합니다. 다만 라우팅 테이블·DNS·다른 VPN과 충돌하면 «인터넷 전체가 끊긴다»는 부작용도 흔합니다. Windows에서는 TUN 후 단절·방화벽 점검 글의 순서대로 가상 어댑터와 route print를 확인하는 것이 좋습니다.

TUN 없이 프로세스 규칙과 일반 리스너만으로 음성이 안정되는 경우도 있습니다. 증상이 «Discord에만 국한»되는지 «모든 앱」인지에 따라 우선 시도할 모드가 달라집니다. 전체가 끊기면 TUN보다 DNS·충돌 앱을 먼저 보고, 음성만 이상하면 프로세스·UDP·노드 순으로 좁혀 가세요. LAN 공유·Mixed Port를 쓰는 경우 Mixed Port·방화벽 글과 설정이 어긋나지 않는지도 확인합니다.

7. 규칙 예시(개념 스켈레톤)

아래는 이해를 돕기 위한 예시이며, 실제 키 이름·문법은 사용 중인 Mihomo 버전과 GUI 문서를 따르세요. 프로세스 조건 토큰은 버전별로 다를 수 있습니다.

# Conceptual example — adapt to your Mihomo / client version
rules:
  - PROCESS-NAME,discord.exe,PROXY-VOICE
  - DOMAIN-SUFFIX,discord.com,PROXY-VOICE
  - DOMAIN-SUFFIX,discordapp.com,PROXY-VOICE
  - MATCH,DIRECT

PROXY-VOICE는 사용자 정의 그룹이어야 하며, 음성에는 출구가 자주 바뀌는 순수 지연 최소 그룹보다는 안정적인 select·fallback을 검토하는 편이 낫습니다. 지연 숫자만 보고 자동으로 노드를 바꾸면 세션이 흔들려 음성 끊김이 심해질 수 있습니다. 규칙을 넣은 뒤에는 반드시 실제 채널에서 몇 분씩 통화하며 체감을 확인하세요.

8. Discord 클라이언트 측에서 할 수 있는 것

프록시 설정과 별개로, Discord 사용자 설정의 음성·비디오 항목에서 입력·출력 장치, 노이즈 제거, 오버레이와의 조합을 점검하는 것은 기본입니다. 일부 환경에서는 «서비스 품질 높이기(QoS)» 옵션이 라우터·방화벽과 상호작용해 이상 증상을 낳는 사례가 있어, 네트워크 쪽을 손보는 동안 끄고 비교 실험을 해 볼 가치가 있습니다. 음성 지역(리전) 자동 선택이 불안정하면 인근 리전으로 고정해 보는 것도 방법입니다.

업데이트 직후에만 문제가 생기면 캐시·권한·백신 소프트웨어의 트래픽 검사와의 충돌도 의심합니다. 이런 경우 Clash를 잠시 끄고 동일 증상이 재현되는지 먼저 나누면, «프록시 때문인지 앱·OS 때문인지」를 빠르게 가를 수 있습니다.

9. 증상별 자가 점검

Clash를 쓰는 Windows 환경에서 Discord 음성을 점검할 때 참고할 표입니다.

증상	의심 지점	조치
텍스트·이미지는 되는데 음성만 끊김	UDP 미전달·노드 UDP 미지원	프로세스 규칙·UDP 허용·노드 교체
RTC 연결 중에서 진행 안 됨	방화벽·TUN·DNS·규칙 순서	TUN 글 순서 점검·로그로 매칭 확인
브라우저 Discord는 정상, 앱만 불안정	데스크톱이 시스템 프록시 미준수	discord.exe 프로세스 규칙·TUN 실험
Clash 끄면 정상	규칙·모드·출구 불일치	RULE 모드·그룹 고정·직접 연결 실험

게임과 동시에 음성을 쓸 때만 악화된다면 게임 실행 파일까지 프로세스 분류 범위를 넓혀 보세요. Steam·UDP 가이드의 사고방식이 그대로 이어집니다.

10. 요약

Discord 음성은 HTTP 한 줄로 설명되지 않는 UDP·실시간 경로가 많아, Windows에서 Clash를 켠 상태라면 discord.exe에 대한 프로세스 분류와 UDP 전달·TUN 동작을 로그로 검증하는 흐름이 실무에 잘 맞습니다. 증상이 음성에만 국한되는지 전체 네트워크 문제인지에 따라 TUN을 켤지, 프로세스 규칙만으로 끝낼지 우선순위가 달라집니다. 클라이언트 음성 설정·QoS·리전 옵션은 프록시와 별도 축에서 함께 조정하는 것이 좋습니다.

규칙 세트를 공유받았더라도 본인 PC에서의 매칭 순서와 출구 그룹은 직접 확인하는 것이 안전합니다. 설치 패키지는 공식 다운로드 페이지에서 받고, 오픈 소스 저장소는 빌드·이슈 확인용으로 참고하면 혼선이 적습니다.

→ Clash를 무료로 내려받아 Discord용 프로세스 규칙과 UDP·TUN 설정을 직접 맞춰 보세요