왜 Discord만 텍스트는 되고 음성만 끊길까요?

Discord는 웹·데스크톱·모바일에서 비슷한 화면을 보여 주지만, 네트워크 관점에서는 여러 겹으로 나뉩니다. 로그인·서버 목록·이미지 프리뷰 등은 대개 TCP 기반 HTTPS로 움직이고, 음성 채널은 UDP를 중심으로 한 실시간 미디어와, 방화벽 뒤에서는 STUN·TURN 같은 보조 경로가 함께 붙습니다. 사용자가 Clash로 「해외 사이트는 프록시」처럼 규칙을 잡았을 때, TCP 트래픽만 정책에 들어오고 UDP가 시스템 프록시 밖으로 새면 채팅은 살아 있어도 음성만 끊기거나 지연이 튀는 상황이 자주 재현됩니다.

또 다른 흔한 원인은 프록시 규칙의 적용 순서입니다. discord.com만 프록시로 묶어 두었는데 실제 보이스는 IP로 직접 나가거나, discord.gg·CDN·별도 호스트가 GEOIP나 국내 DIRECT 규칙에 먼저 걸려 서로 다른 출구로 나뉘면 세션이 불안정해질 수 있습니다. 여기에 DNS가 Clash 안팎으로 갈라지면 이름 해석 결과가 규칙 매칭과 맞지 않아, 겉으로는 연결됐다가 음성 패킷만 다른 경로로 흐르는 패턴도 생깁니다.

즉 「Discord Clash」를 말할 때는 HTTPS 한 줄이 아니라 UDP 분류와 음성 서버 지역, 그리고 필요 시 TUN까지 같은 지도 위에 올려야 합니다. 텍스트 위주 메신저 트래픽만 다뤘던 Telegram 분류 가이드와 달리, 본 글은 음성 끊김과 UDP에 초점을 둡니다.

Discord 트래픽을 층으로 나누면

실무에서는 먼저 증상을 나눕니다. 앱이 아예 로그인되지 않거나 웹만 회색 화면이면 TCP·TLS 구간과 DNS부터 보는 것이 맞고, 채팅·이미지는 되는데 음성 채널에만 들어가면 끊기면 UDP·WebRTC·릴레이 쪽을 의심합니다. Discord는 지역과 서버 부하에 따라 붙는 음성 엔드포인트가 바뀌므로, 노드를 바꿀 때마다 완전히 같은 IP만 쓰는 것도 아닙니다. 그래서 특정 DOMAIN만 프록시하는 구성만으로는 한동안 잘 되다가, 음성 전용 구간이 다른 정책을 타면서 끊기는 경우가 있습니다.

UDP는 TCP와 달리 「연결」이라는 추상화가 사용자에게 덜 보이기 때문에, 연결 로그에서 목적지 포트·프로토콜을 확인하는 습관이 중요합니다. 클라이언트가 시스템 프록시를 따르지 않고 직접 소켓을 연다면, 브라우저는 정상인데 앱만 문제라는 전형적인 패턴이 됩니다. 이때는 TUN 모드로 애플리케이션 트래픽을 같은 프록시 규칙 아래로 가져오는지부터 판단하는 편이 빠릅니다.

💡
Steam·게임 글과의 차이 게임 스토어·다운로드는 주로 TCP·대용량 HTTP에 가깝습니다. Discord 음성은 짧은 주기의 UDP와 NAT 우회가 핵심이라, DNS만 맞추고 끝내기 어렵습니다. Steam 분류 가이드와 병행할 때도 음성 전용 점검을 별도로 두세요.

UDP 분류와 TUN: 왜 시스템 프록시만으로는 부족할까

Windows·macOS에서 흔한 시스템 프록시는 대부분 HTTP·HTTPS용 경로를 열어 줍니다. 애플리케이션은 이 경로를 따르지 않고 UDP 소켓을 직접 열 수 있고, 음성 스택은 그쪽으로 많이 옵니다. Clash 계열에서 UDP 분류를 제대로 쓰려면, 코어가 해당 패킷을 잡아서 정책 그룹으로 보낼 수 있어야 합니다. 그 전제가 되는 것이 TUN(가상 어댑터) 기반의 전역 캡처이거나, 클라이언트가 SOCKS5·HTTP 프록시로 UDP를 명시적으로 넘기는 경우입니다.

공항 노드 설정에서 udp: true 류의 표기가 꺼져 있으면 음성용 UDP가 노드 쪽에서 거절될 수도 있습니다. 서버와 클라이언트 설정이 맞는지, 그리고 UDP 지연이 TCP보다 크게 흔들리지 않는지는 실제 통화 중 로그와 지연 측정으로 확인하는 편이 정확합니다. 「프록시 규칙」에 Discord 관련 DOMAIN을 쌓아도 UDP 레이어가 비어 있으면 체감으로는 여전히 음성 끊김이 남습니다.

DOMAIN 규칙 초안: 로그를 보며 좁히기

아래는 골격 예시입니다. DISCORD는 실제 프로필의 프록시 그룹 이름으로 바꾸고, 환경에 따라 Rule Provider나 추가 DOMAIN을 보강하세요. Discord가 쓰는 호스트 이름은 시간에 따라 늘 수 있으므로, 연결 로그에 찍힌 실제 목적지를 기준으로 하는 것이 가장 안전합니다.

proxy-groups:
  - name: DISCORD
    type: select
    proxies:
      - PROXY
      - DIRECT

rules:
  - DOMAIN-SUFFIX,discord.com,DISCORD
  - DOMAIN-SUFFIX,discordapp.com,DISCORD
  - DOMAIN-SUFFIX,discord.gg,DISCORD
  - DOMAIN-SUFFIX,discord.media,DISCORD
  - DOMAIN-SUFFIX,discordcdn.com,DISCORD
  - DOMAIN-SUFFIX,discordstatus.com,DISCORD
  # Extend with IP-CIDR / RULE-SET from connection logs for UDP-only flows

핵심은 규칙 순서입니다. 앞쪽에 매우 넓은 GEOIP,CN,DIRECT 같은 줄이 있고 Discord 전용 규칙이 뒤에만 있으면, 실제 매칭은 기대와 다르게 나올 수 있습니다. 스플릿 라우팅 최적화에서 설명한 것처럼, 중요한 앱 전용 규칙은 가능한 한 앞당기고, 범용 규칙은 뒤에서 받는 편이 디버깅에 유리합니다.

음성 지역 라우팅: 클라이언트 설정과 노드

Discord 앱에는 음성 영역과 관련된 설정(서버·채널 단위)이 있습니다. 물리적으로 가깝다고 해서 항상 지연이 최소는 아니지만, 선택한 음성 서버 지역과 프록시 노드 위치가 지나치게 엇나가면 왕복 시간이 불필요하게 길어질 수 있습니다. 예를 들어 음성은 아시아 리전을 쓰는데 프록시 출구만 유럽에 두면, TCP 기반 UI는 버티더라도 UDP 음성이 왕복 지연에 더 민감하게 반응할 수 있습니다.

실무에서는 먼저 동일한 DISCORD 정책 그룹 안에서 지연·손실이 낮은 노드 한두 개를 고정해 보고, 그다음 Discord 측 음성 품질 설정(하드웨어 가속·입력 장치)을 점검합니다. 짧은 주기로 노드를 자동 전환하는 url-test만 의존하면 세션이 갈아타며 음성 끊김이 커질 수 있으므로, 음성 위주 사용 시에는 Selector로 안정 노드를 유지하는 편이 낫습니다.

STUN·TURN과 NAT: 음성이 방화벽에서 막힐 때

일부 네트워크는 UDP를 제한하거나 대칭 NAT 때문에 WebRTC 협상이 실패하기도 합니다. 이때 앱은 릴레이로 우회하려 하며, 그 경로 역시 Clash 규칙과 DNS에서 일관되게 잡혀 있어야 합니다. 어떤 환경에서는 「Discord만 예외로 열어라」는 식의 관리형 프록시·방화벽 정책이 음성보다 텍스트만 허용하는 경우도 있어, 회사망에서는 기술만으로 해결이 안 되는지도 구분해야 합니다.

DNS 모드는 fake-ip와 redir-host 비교에서 다룬 것처럼 앱별로 체감이 다릅니다. 음성은 이름과 IP가 규칙 매칭에 동시에 걸리는 경우가 많아, DNS와 TUN·시스템 프록시가 한 흐름인지 반복해서 확인하는 것이 좋습니다.

증상별로 원인 좁히기

로그인·서버 목록만 안 될 때

TCP·TLS·DNS 쪽 가능성이 큽니다. discord.com 관련 DOMAIN이 DIRECT로만 나가거나 이름 해석이 실패하는지 연결 로그와 브라우저 개발자 도구를 함께 보세요.

채팅은 되는데 음성만 안 될 때

UDP 분류, 노드의 UDP 허용, TUN 미적용, 혹은 음성 전용 호스트가 다른 규칙에 먼저 걸린 경우를 의심합니다. 로그에서 UDP 목적지와 최종 정책을 확인합니다.

모바일은 되고 PC만 불안정할 때

OS 프록시를 따르지 않는 데스크톱 바이너리, 방화벽 예외, 다른 VPN·보안 소프트웨어와의 충돌을 점검합니다. 필요하면 TUN으로 동일 앱이 같은 규칙을 타는지 확인합니다.

점검 순서: 최소 재현부터

  1. 연결 로그를 켠 상태에서 음성 채널에 입장해 문제를 재현하고, 첫 실패·지연 스파이크가 난 호스트와 매칭된 정책을 기록합니다.
  2. DIRECT로 나가는 Discord 관련 줄이 있다면 프록시 규칙 앞쪽에 DOMAIN·RULE-SET을 보강합니다.
  3. DISCORD 그룹을 지연·손실이 낮은 노드로 고정하고, 짧은 주기 자동선택은 잠시 끕니다.
  4. TUN 또는 앱이 프록시 UDP를 쓰도록 할 수 있는지 확인하고, 노드 측 UDP 지원 여부를 봅니다.
  5. DNS·fake-ip·nameserver를 바꾼 뒤에는 코어 재시작과 OS DNS 캐시 초기화까지 한 세트로 진행합니다.

규칙 자체가 꼬였는지 가르는 자세한 방법은 연결 로그·규칙 적중 튜토리얼과 같은 순서로 따라가면 됩니다.

⚠️
준수 사항 거주 지역의 법령과 학교·회사 네트워크 정책, Discord 이용약관을 지켜 주세요. 본문은 합법적으로 접근 가능한 환경에서 기술적 경로를 정렬하는 데 초점을 둡니다.

정리: Discord Clash는 TCP와 UDP를 한 세트로

로그인·채팅을 살렸다고 해서 음성까지 자동으로 안정되지는 않습니다. Discord Clash를 검색해 설정을 찾는 사용자에게는 UDP 분류와 음성 서버 지역, TUN·프록시 규칙 순서가 같은 문맥으로 묶여 있어야 실패 재현이 줄어듭니다. 노드를 옮기기 전에 로그로 실제 매칭을 확인하고 YAML을 고치면, 시행착오 시간을 크게 줄일 수 있습니다.

클라이언트 설치가 처음이라면 문서 센터와 구독 가져오기 가이드를 먼저 밟은 뒤, 이 글의 규칙과 TUN 점검을 얹으면 흐름이 끊기지 않습니다. 설치 패키지는 여러 포크 중 무엇이 최신인지 헷갈리기 쉬우므로, 본 사이트 다운로드 페이지에서 플랫폼별로 정리된 빌드를 쓰면 출처 혼선을 줄일 수 있습니다. 준비가 되었다면 → Clash를 무료로 내려받아 Discord 음성까지 한 번에 안정화해 보세요.