Discord 음성·게임 UDP 지연? Clash TUN과 릴레이 노드로 웹과 음성을 나누기

증상으로 보는 원인 후보

같은 “프록시 켬”이라도 HTTPS 웹과 UDP 음성은 겪는 문제가 다릅니다. 웹은 대체로 버퍼링으로 흡수되지만, 음성은 짧은 지터만 있어도 끊김으로 체감됩니다. 아래는 로그를 보기 전에도 체크리스트로 쓸 수 있는 패턴입니다.

• 텍스트·이미지는 되는데 음성만 끊김: UDP·RTP 계열이 다른 출구를 타거나, 노드가 UDP를 제한·재순서하는 경우.
• 나만 안 들리거나 상대만 안 들림: 비대칭 경로, 방화벽·캐리어급 NAT, 또는 Discord가 직접/릴레이를 섞을 때 한쪽만 터널을 탄 경우.
• 게임 핑은 괜찮은데 디스코드만 밀림: 게임 실행 파일은 DIRECT인데 Discord.exe만 무거운 해외 릴레이로 나가는 등 프로세스별 정책 불균형.
• 전역 프록시일 때만 발생: TUN이 모든 UDP를 한 그룹으로 몰아넣는 구조일 가능성.

TUN이 UDP·음성에 미치는 영향

TUN은 브라우저가 시스템 프록시를 무시해도 커널 근처에서 트래픽을 가로채므로, Discord 데스크톱 앱·게임 클라이언트의 UDP까지 Clash 규칙 테이블로 들어옵니다. 장점은 분류가 일관된다는 것이고, 단점은 설정이 어색하면 원치 않는 UDP까지 같은 지연 큐를 탈 수 있다는 점입니다. Meta(Mihomo) 계열은 PROCESS-NAME·PROCESS-PATH로 실행 파일 단위로 쪼갤 수 있어, “크롬만 프록시”보다 한 단계 정밀하게 음성 앱을 분리할 수 있습니다.

Windows에서 TUN 기준선이 없다면 《Clash for Windows 설치》부터 맞추고, macOS는 《Clash Verge Rev macOS》에서 확장 권한을 통과한 뒤 음성 분리를 시도하세요. DNS가 흔들리면 음성보다 먼저 연결이 꼬입니다—필요하면 《DNS·fake-ip》 글의 순서를 따릅니다.

「웹만 프록시」와 「UDP 친화 노드」를 나누는 법

현실적인 목표는 두 층입니다. 첫째, 브라우저·업데이트·OAuth처럼 TCP 위주 트래픽은 안정적인 상용 노드로 보낸다. 둘째, Discord 음성·일부 게임 보이스는 가능하면 지연과 지터가 낮은 출구에 두거나, 정책상 허용된다면 직연결로 빼서 터널 홉을 줄인다. “전부 DIRECT”는 웹 접속이 막힐 수 있고, “전부 PROXY”는 음성이 불안정해질 수 있어, 하이브리드가 대부분의 해법입니다.

Discord는 음성 경로가 사용자 설정·리전·혼잡도에 따라 직접 UDP와 릴레이를 오갈 수 있습니다. 그래서 노드 하나만 바꿔도 “어제는 괜찮았는데 오늘은 한쪽 무음”이 생길 수 있습니다. 릴레이를 강제로 켜거나 끄는 클라이언트 옵션과 Clash 쪽 정책이 동시에 작용하므로, 앱 설정과 규칙을 함께 보는 것이 중요합니다.

PROCESS-NAME으로 Discord·게임을 분리

Windows 데스크톱 기준으로 흔한 실행 파일은 Discord.exe입니다(업데이트 후 이름이 바뀌지 않았는지 작업 관리자로 확인). Electron 기반 오버레이·서브프로세스가 추가로 뜰 수 있으니, 클라이언트 로그에서 실제로 음성에 쓰인 프로세스를 한 번 찍어두는 것이 안전합니다. 게임은 타이틀마다 실행 파일이 다르므로, “도메인만으로 게임 UDP를 예쁘게 나눈다”는 접근은 한계가 있고, 매치 중인 바이너리를 DIRECT로 두는 방식이 더 예측 가능한 경우가 많습니다.

규칙은 반드시 넓은 GEOIP나 최종 MATCH보다 위쪽에 둡니다. 그렇지 않으면 프로세스 행이 영원히 승리하지 못합니다. 아래는 개념 예시이며, 그룹 이름과 프로세스 철자는 본인 환경에 맞게 바꿉니다.

# Illustrative rules — verify process names on your OS
rules:
  - PROCESS-NAME,Discord.exe,DISCORD_PROXY
  - PROCESS-NAME,SomeGame.exe,DIRECT
  - DOMAIN-SUFFIX,discord.com,PROXY
  - MATCH,PROXY

DISCORD_PROXY는 “음성에 쓸 저지연 전용 그룹”으로 두고, 일반 웹은 PROXY에 두는 식으로 쪼개면 튜닝이 쉬워집니다. 반대로 음성을 아예 직연결하고 싶다면 해당 프로세스 행을 DIRECT로 두되, 그 경우에도 Discord 로그인·CDN이 깨지지 않는지 텍스트 채널로 확인하세요.

릴레이·노드 프로토콜 관점에서 UDP 지연 줄이기

스피드테스트 점수는 대용량 TCP에 유리한 경우가 많고, 작은 UDP 패킷이 많은 음성·일부 게임 트래픽과 상관이 약할 수 있습니다. 노드의 프로토콜 스택(VMess, VLESS, Trojan, Hysteria2 등)과 서버 측 UDP 포워딩 품질, 백홀 라우팅이 합쳐져 체감 지연이 결정됩니다. “한 홉 릴레이”라도 그 홉이 혼잡하면 지터가 커지므로, 음성 전용 그룹에는 헬스 체크 간격을 너무 공격적으로 짧게 두어 플랩하지 않게 조정하는 편이 낫습니다.

구독에 릴레이·중계 노드가 따로 있다면, 웹용 글로벌 출구와 음성용 근거리 출구를 분리해 보세요. 지리적으로 가깝다고 RTT만 좋은 것은 아니지만, 불필요한 대륙 편도를 줄이는 데는 여전히 유효합니다. 멀티프로토콜 지원 클라이언트라면 음성 그룹만 다른 프로토콜을 시험하는 것도 방법입니다—단, 한 번에 한 가지만 바꿔 원인을 좁히세요.

고려 요소	음성·UDP에 미치는 점	실무 팁
이중 터널·중첩 VPN	UDP NAT 매핑이 꼬이기 쉬움	가능하면 한 겹으로 단순화
노드 UDP 차단·QoS	단방향 무음·주기적 끊김	다른 서버·프로토콜로 A/B
fake-ip·DNS	앱이 기대하는 주소와 불일치	도메인 규칙과 nameserver 정렬

인게임 보이스와 게임 트래픽

일부 타이틀은 게임 서버와 보이스 채널이 서로 다른 호스트·포트를 씁니다. Clash에서는 둘 다 같은 실행 파일에서 나가므로 PROCESS-NAME만으로는 세분화가 부족할 수 있고, 이때는 로그에 찍힌 목적지 IP·포트를 보고 좁은 IP-CIDR나 도메인 규칙을 보조로 얹습니다. 경쟁 매치가 중요하면 게임 본체를 DIRECT로 두고, 플랫폼 런처만 프록시하는 패턴이 Steam·Epic TUN 글과 잘 맞물립니다.

안티치트와 가상 어댑터의 상호작용은 제품마다 다릅니다. TUN을 끈 상태와 켠 상태를 번갈아 비교해 “규칙 문제인지 드라이버 충돌인지”를 먼저 가르세요.

Discord 클라이언트 측과의 정렬

클라이언트의 음성 디버그·RTC 로그(버전에 따라 메뉴 이름이 다름)에서는 지연·패킷 손실·릴레이 사용 여부를 볼 수 있습니다. Clash에서 노드를 바꿨을 때 이 수치가 같이 움직이면 해당 UDP 세션이 여전히 터널을 타고 있다는 뜻입니다. 입력 장치·AGC 문제와 구분하려면, 동일 하드웨어에서 TUN만 끄고 재현되는지도 확인하세요.

FAQ

한쪽만 소리가 들려요

비대칭 경로나 UDP NAT 문제일 수 있습니다. 이중 터널을 제거하고, Discord 프로세스가 기대한 정책 그룹을 타는지 로그로 확인하세요.

브라우저 Discord는 괜찮은데 앱만 이상해요

브라우저는 시스템 프록시를 따르고 앱은 TUN을 탈 수 있습니다. 앱 전용 PROCESS-NAME 행을 추가해 동작을 맞춥니다.

연결은 되는데 자주 끊겨요

노드 플랩·공유기 UDP 타임아웃·헬스 체크 과잉을 의심하세요. 음성 그룹의 서버를 줄이고 안정적인 것만 남겨 보는 것도 방법입니다.

정리

Discord·게임 음성의 지연은 “대역폭”보다 경로·UDP 처리·DNS의 합입니다. Clash TUN은 그 지점을 한곳으로 모아 주므로, PROCESS-NAME과 정책 그룹을 잘 쓰면 웹과 음성을 분리해 체감 품질을 끌어올릴 수 있습니다. 스토어·런처 분류는 별도 글과 조합해 전체 그림을 완성하세요.

Clash를 무료로 내려받고 차이를 경험해 보세요