Discord가 연결되지 않거나 음성이 끊길 때: Clash TUN과 도메인 분기로 프로세스·UDP를 덮는 실측 (2026)

1. 웹은 되는데 앱·음성만 이상한 패턴

브라우저에서 discord.com을 열면 로그인 화면이 뜨는데, Electron 기반 데스크톱 앱은 무한 연결이거나, 서버 목록은 보이는데 특정 길드만 비어 보이는 경우가 있습니다. 음성 채널은 더 민감합니다. 텍스트 채팅은 TCP 위주로도 버티는 편인데, 보이스 RTP류는 UDP와 낮은 지터를 전제로 설계되어 있어, 회선 중간에서 UDP가 깎이거나 다른 경로로 새면 바로 끊깁니다. 사용자 입장에서는 「Wi-Fi에서는 되는데 유선만 안 된다」처럼 물리층과 무관해 보이는데, 실제로는 앱이 붙는 호스트 이름과 음성 게이트웨이가 웹 세션과 달라서 그렇게 보이는 경우가 많습니다.

또 하나의 흔한 착시는 시스템 프록시를 켰다고 해서 모든 프로세스가 같은 출구를 쓴다고 가정하는 것입니다. Windows와 macOS 모두, 앱이 WinINet·시스템 프록시 스택을 존중하지 않으면 HTTP 프록시 설정과 무관하게 직접 소켓을 엽니다. Discord 데스크톱은 그런 카테고리에 가깝고, 음성은 애초에 프록시 레이어 밖 동작을 전제로 한 프로토콜이 섞입니다. 그래서 증상을 좁힐 때는 먼저 어떤 호스트가 타임아웃인지를 로그로 확정하고, 그다음 TUN으로 트래픽을 가로챌지를 결정하는 편이 재현에 유리합니다.

2. 시스템 프록시(HTTP/SOCKS)만으로는 왜 부족한가

전통적인 시스템 프록시는 주로 HTTP CONNECT나 SOCKS5를 통해 TCP 연결을 중계합니다. 브라우저·일부 SDK는 이 경로를 따르지만, 데스크톱 Discord는 내부적으로 WebSocket·HTTP/2·QUIC 등 여러 스택을 섞고, 음성은 별도의 미디어 경로를 탑니다. 여기서 중요한 것은 「시스템에 프록시 주소가 적혀 있다」와 「해당 프로세스의 모든 패킷이 Clash로 간다」는 다르다는 점입니다. 규칙 모드에서도, 앱이 시스템 프록시를 무시하면 Clash의 도메인 규칙이 적용되기 전에 OS 스택으로 나가 버립니다.

SOCKS5가 UDP ASSOCIATE를 지원하더라도, 클라이언트가 그 경로를 실제로 쓰는지는 또 다른 문제입니다. 음성 품질은 RTT뿐 아니라 지터·패킷 손실에 민감해서, 이중 터널·불필요한 홉이 생기면 체감이 크게 나빠집니다. 실무에서는 TUN 인터페이스를 올려 IP 레이어에서 라우팅시키고, mihomo가 해당 플로우를 정책 그룹에 매칭하도록 만든 뒤, Discord 관련 접미 도메인을 한 그룹에 묶어 출구를 고정하는 방식이 증상 재현과 완화 모두에서 다루기 쉽습니다. 전체 트래픽을 무조건 프록시로 보내는 글로벌 VPN과는 목적이 다르니, 규칙 기반 분기라는 전제를 잃지 않는 것이 좋습니다.

Clash 계열에서 모드와 스택의 관계는 Clash 개요와 TUN 모드 설명을 함께 보면 이해가 빨라집니다. 특히 TUN이 Slack·Discord 같은 데스크톱 앱을 예로 드는 이유는, 바로 이 프록시 우회·UDP 이슈 때문입니다.

3. UDP·음성과 TUN이 겹치는 지점

Discord 보이스는 지역·부하에 따라 게이트웨이 호스트가 달라지고, 미디어 패킷은 UDP를 사용하는 경로가 일반적입니다. 일부 네트워크는 TCP 443은 허용하지만 UDP를 제한하거나, NAT 뒤에서 세션 테이블이 짧아 음성만 끊기는 패턴을 만듭니다. Clash 쪽에서는 TUN을 켰을 때 해당 UDP 플로우가 mihomo의 라우팅 테이블을 타는지, 그리고 의도한 아웃바운드로 매칭되는지가 핵심입니다. 여기서 DNS가 Clash 밖에서 먼저 풀리면, 규칙에 넣은 도메인과 실제 연결 대상 IP가 어긋나는 fake-ip·스니퍼 불일치가 음성에 더 크게 드러날 수 있습니다.

TUN을 켠다고 모든 문제가 사라지는 것은 아닙니다. 노드가 UDP를 제대로 포워딩하지 않거나, 지역이 멀어 RTT가 커지면 음성은 여전히 불안정합니다. 다만 「앱이 시스템 프록시를 안 타서 규칙이 안 먹는다」와 「UDP가 아예 다른 출구로 새고 있다」 같은 케이스는 TUN과 DNS를 맞춘 뒤에야 비로소 노드 품질 이슈로 좁혀집니다. 그래서 이 글은 하드웨어 마이크 설정이나 Discord 내부 음성 인코더가 아니라, 네트워크 스택에서의 검증 순서에 초점을 둡니다.

4. 규칙에 넣기 좋은 Discord·CDN 도메인

Discord는 기능 추가와 인프라 이전으로 호스트가 바뀔 수 있으므로, 아래는 출발점입니다. 실패가 반복되면 mihomo 로그에 찍힌 CLIENT-NAME / DOMAIN / IP를 그대로 복사해 규칙에 추가하세요. 흔히 묶는 접미에는 discord.com, 레거시 호환으로 자주 등장하는 discordapp.com, 초대 링크에 쓰이는 discord.gg, 음성·세션에 연결되는 gateway.discord.gg, 이미지·첨부에 연결되는 media.discordapp.net, 정적 자산의 cdn.discordapp.com 등이 있습니다. 클라이언트 업데이트에는 updates.discord.com이 등장하기도 합니다.

길드 아이콘·임베드 썸네일처럼 긴 서브도메인이 붙은 CDN 호스트는 시간대에 따라 이름이 바뀔 수 있습니다. 이때 DOMAIN-SUFFIX,discordapp.net처럼 접미로 잡는 것이 유지보수에 유리한 경우가 많습니다. 반대로 DOMAIN-KEYWORD,discord처럼 지나치게 넓은 키워드는 다른 서비스까지 끌어와 지연을 키울 수 있어 비추천입니다. Steam 대용량 CDN 튜닝을 다룬 Steam 분기 글과 달리, Discord는 실시간 음성·작은 패킷 비중이 크므로 노드 그룹을 고정하는 쪽이 체감에 유리한 경우가 많습니다.

5. mihomo 규칙 스니펫과 우선순위

전용 정책 그룹 이름을 예시로 💬 Discord라고 하면, rules 상단에서 넓은 GEOIP나 MATCH보다 앞쪽에 Discord 묶음을 두는 형태가 일반적입니다. 그룹명·프록시 이름은 구독 프로필에 맞게 바꿉니다. 규칙 우선순위 개념은 고급 라우팅 가이드와 함께 보면 실수가 줄어듭니다.

rules:
  # Discord — keep above broad GEOIP / MATCH
  - DOMAIN-SUFFIX,discord.com,💬 Discord
  - DOMAIN-SUFFIX,discordapp.com,💬 Discord
  - DOMAIN-SUFFIX,discord.gg,💬 Discord
  - DOMAIN-SUFFIX,discordapp.net,💬 Discord
  - DOMAIN,gateway.discord.gg,💬 Discord
  - DOMAIN-SUFFIX,updates.discord.com,💬 Discord
  # Append hosts from live logs (CLIENT-NAME / DOMAIN)

  # ... LAN, CN, then MATCH
  - GEOIP,PRIVATE,DIRECT
  - MATCH,🔰 Proxy

구독 갱신 시 사용자 규칙이 덮어쓰이지 않게 하려면 프로필 머지 순서를 확인하세요. Windows에서 Microsoft Store 앱과 UWP만 예외로 깨질 때는 TUN·UWP 루프백 글의 절차를 병행하는 것이 좋습니다. macOS 사용자는 Gatekeeper·시스템 확장 이슈를 Verge Rev macOS 가이드와 함께 점검하면 TUN 활성화 실패를 빨리 걸러낼 수 있습니다.

6. DNS·fake-ip·DoH 누수와의 관계

Discord 클라이언트가 붙기 전에 OS나 브라우저의 DoH가 먼저 이름을 풀면, Clash의 스니퍼가 기대하는 흐름과 달라져 규칙이 엇나갈 수 있습니다. 특히 fake-ip 모드에서는 DNS 응답과 실제 연결이 한 세트로 움직여야 하는데, 일부 앱만 Clash DNS를 쓰지 않으면 「규칙은 맞는 것 같은데 음성만 이상하다」가 됩니다. 점검 순서로는 먼저 Clash DNS 화면에서 쿼리가 들어오는지 확인하고, 시스템 네트워크 설정에 고정 DoH가 박혀 있으면 테스트 동안만 끄거나 Clash 쪽으로 일원화해 재현을 비교합니다.

SNI 기반 규칙을 쓰는 환경이라면 TLS 핑거프린트와 함께 음성 UDP가 다른 경로로 나가지 않는지도 봐야 합니다. 이 글은 특정 DNS 프로바이더를 권장하지 않으며, 로그에 찍힌 실패 지점을 기준으로 쿼리 경로를 정리하는 방법을 권합니다. 회사 장비에서는 DNS 조작 자체가 정책 위반이 될 수 있으니, 사전 승인 범위 안에서만 실험하세요.

장기적으로는 구독 URL 갱신이 불안정할 때 쓰는 Windows 구독·TLS·DNS 로그 절차와 비슷하게, DNS 단계 로그 → 다이얼 단계 로그 순으로 좁히면 Discord에도 그대로 이식할 수 있습니다.

7. 실측 검증: 로그·음성 채널·지연

권장 루틴은 다음과 같습니다. 첫째, TUN을 켠 상태에서 데스크톱 Discord를 완전히 종료한 뒤 다시 실행하고, 로그인 직후에 로그에 뜨는 호스트가 DOMAIN-SUFFIX 묶음에 매칭되는지 확인합니다. 둘째, 아무 음성 채널에 들어가 말하기 없이 1~2분 대기하며 끊김이 재현되는지 봅니다. 셋째, 같은 계정으로 웹 Discord를 열어 동일 길드의 음성에 참여해 보고, 웹만 안정적인지 비교합니다. 넷째, Proxies 화면에서 Discord 그룹이 가리키는 노드를 수동으로 바꿔 RTT와 체감을 교차 검증합니다.

로그에서 확인할 키워드는 매칭된 규칙 타입, 도메인 또는 IP, 선택된 아웃바운드의 세 튜플이 연속으로 일치하는지입니다. 한 호스트만 다른 그룹으로 새면 길드 아이콘은 뜨는데 음성만 실패하는 식으로 갈라집니다. Discord 자체의 통화 품질 표시와 함께, OS 방화벽이나 보안 제품이 가상 어댑터 트래픽만 차단하지 않는지도 확인하세요. 이는 Clash 문제가 아니라 로컬 정책 문제인 경우가 많습니다.

8. Windows·macOS에서 함께 볼 글

Windows 11에서 Verge Rev를 쓰는 경우, 시스템 프록시와 TUN을 처음 맞출 때는 Windows 11 Verge Rev 가이드의 순서를 밟은 뒤 Discord를 켜면 변수가 줄어듭니다. 이미 TUN은 되는데 특정 Microsoft 앱만 직접 연결을 고집한다면 UWP 루프백 글을 우선 적용합니다. macOS는 시스템 확장 승인과 Full Disk Access 같은 권한 이슈가 TUN 활성화를 가릴 수 있으니, 위에 인용한 macOS 가이드를 먼저 통과시키는 편이 빠릅니다.

정책 그룹이 url-test로 자주 바뀌면 음성 세션이 끊길 수 있습니다. 이때는 url-test·fallback 글의 아이디어를 참고해 Discord 그룹만 수동 선택이나 안정적인 fallback으로 고정하는 것도 한 방법입니다.

9. 정책·주의·마무리

Discord는 지역 약관·커뮤니티 가이드라인·저작권 정책이 복잡합니다. 본문은 네트워크 경로를 좁히는 기술적 체크리스트에만 초점을 맞추었으며, 서비스 이용 자체의 적법성·계정 안전은 각 지역 규정과 Discord 약관을 따릅니다. 학교·회사 장비에서는 프록시·TUN 사용이 금지될 수 있으니 IT 정책을 먼저 확인해야 합니다.

정리하면, 2026년에도 흔한 Discord 불안정 패턴은 ① 로그로 실패 호스트 확정 → ② TUN으로 프로세스·UDP 경로를 Clash에 태움 → ③ mihomo에서 Discord·CDN 접미를 전용 정책 그룹으로 묶음 → ④ DNS·fake-ip·DoH 누수 제거 → ⑤ 노드·UDP 품질 교차 검증 순서로 좁히는 것이 재현에 유리합니다. Steam의 대용량 CDN이나 Disney+ 재생 세션과 달리, 여기서는 낮은 지터 UDP와 데스크톱 앱의 프록시 우회가 같은 표 위에 올라옵니다.

→ Clash를 무료로 내려받아 최신 클라이언트에서 TUN·규칙·로그를 한 흐름으로 점검하고, Discord 로그인·음성 채널을 같은 실측 루틴에 넣어 보세요. 규칙 생태계가 넓어 출구를 고정하고, 노드 그룹과 조합했을 때 증상을 분리하기 쉬운 편입니다.