Telegram이 연결되지 않거나 동기화·미디어가 멈출 때: MTProto·관련 도메인을 Clash(mihomo)로 분기하는 실측 (2026)

1. 흔한 증상: 타임아웃·동기화·업데이트

모바일 앱에서는 백그라운드에서 푸시가 오다가도, Wi-Fi만 켜면 「연결 중…」에서 벗어나지 못하거나, 특정 채팅방만 메시지가 비어 있는 것처럼 보일 수 있습니다. 데스크톱 Telegram은 api.telegram.org나 CDN 호스트에 대한 TLS 연결이 끊기면 목록은 보이는데 미디어 썸네일만 계속 돌거나, 업데이트 패키지를 받다 멈춘 채로 남기도 합니다. 이런 패턴은 단일 노드가 느려서만 생기지 않고, 일부 호스트만 DIRECT로 빠지거나 DNS가 Clash 밖에서 먼저 풀려 규칙에 넣은 도메인과 실제 연결 IP가 어긋나는 경우에도 비슷하게 보입니다.

사용자가 앱 안에서 MTProto 프록시를 직접 넣는 방법도 있지만, 이는 Clash의 도메인 규칙·정책 그룹과는 별 축입니다. 본문은 후자를 전제로, 로그에 찍힌 DOMAIN·SNI·아웃바운드를 기준으로 출구를 고정하는 순서를 다룹니다. 먼저 증상을 텍스트 채팅·미디어·통화·업데이트로 나누어 어느 단계에서 끊기는지 적어 두면, 아래 절차를 밟을 때 변수가 줄어듭니다.

2. MTProto·클라이언트 트래픽을 어디까지 묶을까

MTProto는 Telegram이 쓰는 전송·암호화 스택을 가리키는 말로 검색에 자주 붙습니다. 실무에서 Clash 사용자가 손대는 것은 프로토콜 세부사항이라기보다 어떤 서버 이름으로 나가는 TCP·UDP 플로우를 어느 정책 그룹에 태울지입니다. 모바일과 데스크톱 모두 *.telegram.org 계열과 t.me 딥링크, 배포·통계에 쓰이는 별도 호스트가 섞입니다. 인프라는 시기에 따라 바뀔 수 있으므로, 아래 도메인 목록은 출발점이고, 반복 실패 시 mihomo 디버그 로그에 나온 이름을 그대로 규칙에 추가하는 방식이 가장 안전합니다.

Clash·mihomo의 강점은 구독 노드 위에 DOMAIN-SUFFIX·GEOIP·PROCESS 등을 겹쳐서, 메신저만 전용 그룹으로 보내고 나머지 트래픽은 기존 규칙을 유지할 수 있다는 점입니다. 전체를 글로벌 VPN처럼 한 출구에 몰아넣지 않아도 된다는 전제를 유지한 채, 증상 재현과 완화를 동시에 보기 쉽습니다.

3. 시스템 프록시만으로는 왜 부족한가

OS에 HTTP/SOCKS 프록시를 넣었다고 해서 모든 프로세스가 같은 경로를 쓰지는 않습니다. Telegram 데스크톱은 설정에서 프록시를 따로 지정할 수 있고, 일부 빌드·환경에서는 시스템 프록시를 무시한 채 직접 소켓을 열기도 합니다. 그러면 Clash 쪽 도메인 규칙이 적용되기 전에 이미 로컬 스택으로 나가 버려, 규칙 모드에서도 기대한 노드로 안 붙는 것처럼 보입니다. 음성·영상처럼 UDP 비중이 큰 흐름은 프록시 레이어 밖 동작을 가정하는 경우가 있어, Discord 음성 글에서 설명한 것과 맥락이 비슷합니다.

이런 이유로 증상을 좁힐 때는 TUN 모드로 IP 레이어에서 트래픽을 가로채고, mihomo가 해당 플로우를 정책 그룹에 매칭하도록 만든 뒤, 텔레그램 관련 접미를 한 그룹에 묶는 방식이 재현에 유리한 경우가 많습니다. 모드와 스택의 관계는 Clash 개요와 TUN 모드 설명을 함께 보면 이해가 빨라집니다.

4. 음성·통화와 UDP·TUN

Telegram 음성·영상 통화는 네트워크 환경에 따라 UDP를 쓰는 경로가 있고, 중간 회선에서 UDP가 제한되면 TCP만 되는 앱과 달리 끊기거나 품질이 크게 떨어질 수 있습니다. TUN을 켠 상태에서 해당 UDP 세션이 의도한 아웃바운드로 매칭되는지, 로그에서 연속성을 확인하는 것이 좋습니다. 같은 맥락의 단계별 설명은 Discord·UDP·TUN 실측 글을 참고하면 음성 쪽 검증 순서를 그대로 이식하기 쉽습니다.

TUN이 만능은 아닙니다. 노드가 UDP를 제대로 포워딩하지 않거나 RTT가 크면 통화 품질은 여전히 불안정합니다. 다만 「규칙이 안 먹어서 DIRECT로 새는」 문제와 「노드 품질 문제」를 분리하려면, TUN·DNS를 맞춘 뒤에야 후자로 좁혀집니다.

5. 규칙에 넣기 좋은 도메인·CDN 접미

자주 묶는 접미에는 telegram.org, 딥링크·프로필에 쓰이는 t.me, 클라이언트·봇 API의 api.telegram.org, 문서·리소스의 core.telegram.org, 웹 클라이언트의 web.telegram.org, 데스크톱 설치·업데이트에 연결되는 desktop.telegram.org·getdesktop.telegram.org 등이 있습니다. 이미지·파일 CDN은 *.cdn.telegram.org 형태로 찍히는 경우가 있어, 로그에 보이는 전체 호스트를 한 번에 복사해 두는 편이 안전합니다.

DOMAIN-KEYWORD,telegram처럼 지나치게 넓은 키워드는 다른 사이트까지 끌어와 지연을 키울 수 있어 비추천입니다. 대신 DOMAIN-SUFFIX,telegram.org와 DOMAIN-SUFFIX,t.me처럼 접미를 나누고, 빠지는 호스트만 로그에서 보강하세요. 구독 갱신이 불안정할 때 DNS를 다루는 절차는 Windows 구독·TLS·DNS 로그 글과 흐름이 비슷해, DNS 단계 → 연결 단계 순으로 좁히는 습관을 같이 들이면 좋습니다.

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

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

rules:
  # Telegram — keep above broad GEOIP / MATCH
  - DOMAIN-SUFFIX,telegram.org,✈️ Telegram
  - DOMAIN-SUFFIX,t.me,✈️ Telegram
  - DOMAIN,api.telegram.org,✈️ Telegram
  - DOMAIN,core.telegram.org,✈️ Telegram
  - DOMAIN,web.telegram.org,✈️ Telegram
  - DOMAIN-SUFFIX,desktop.telegram.org,✈️ Telegram
  - DOMAIN-SUFFIX,getdesktop.telegram.org,✈️ Telegram
  # Append hosts from live logs (DOMAIN / SNI)

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

구독 갱신 시 사용자 규칙이 덮어쓰이지 않게 하려면 프로필 머지 순서를 확인하세요. Windows에서 Microsoft Store 앱만 예외로 깨질 때는 TUN·UWP 루프백 글을 병행하면 변수가 줄어듭니다. macOS는 Verge Rev macOS 가이드로 시스템 확장·권한 이슈를 먼저 걸러 내는 편이 빠릅니다.

7. DNS·fake-ip·DoH 누수

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

HTTPS 트래픽에서 SNI 기반 규칙을 쓰는 환경이라면, Sniffer 관련 로그를 함께 보는 것이 좋습니다. 특정 서비스만 오분기될 때의 사고방식은 Meta Sniffer 글들과 연결되지만, 본문은 텔레그램 호스트를 기준으로 실패 지점을 로그에서 확정하는 방법을 권합니다.

8. 실측 검증 루틴

권장 순서는 다음과 같습니다. 첫째, TUN을 켠 상태에서 Telegram 앱을 완전히 종료한 뒤 다시 실행하고, 로그인 직후 로그에 뜨는 호스트가 DOMAIN-SUFFIX 묶음에 매칭되는지 확인합니다. 둘째, 채팅 목록이 갱신되는 동안 타임아웃이 없는지, 셋째, 스티커·이미지가 많은 방을 열어 미디어 로딩이 같은 정책 그룹을 타는지 봅니다. 넷째, 통화를 켜 보고 UDP 관련 로그가 끊기지 않는지 확인합니다. 다섯째, Proxies 화면에서 Telegram 그룹이 가리키는 노드를 수동으로 바꿔 RTT와 체감을 교차 검증합니다.

로그에서 확인할 것은 매칭된 규칙 타입, 도메인 또는 IP, 선택된 아웃바운드의 세 튜플이 연속으로 일치하는지입니다. 정책 그룹이 url-test로 자주 바뀌면 세션이 끊길 수 있으니, url-test·fallback 글의 아이디어를 참고해 텔레그램 그룹만 수동 선택이나 안정적인 fallback으로 고정하는 것도 방법입니다.

9. 함께 보면 좋은 글

Android에서 앱별로 프록시를 나누는 설정은 Clash Android 앱별 프록시 글과 역할이 겹칩니다. iOS·Stash 사용자는 아이폰 Stash 첫 설정 글을 함께 보면 모바일에서 구독·규칙을 맞추는 순서가 정리됩니다. 구독 URL 자체를 처음 넣는 단계는 구독 가져오기 안내와 병행해도 좋습니다.

Windows 11에서 Verge Rev를 쓰는 경우 시스템 프록시와 TUN을 처음 맞출 때는 Windows 11 Verge Rev 가이드의 순서를 밟은 뒤 Telegram을 켜면 재현이 단순해집니다.

10. 정책·주의·마무리

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

정리하면, 2026년에도 흔한 Telegram 불안정 패턴은 ① 로그로 실패 호스트 확정 → ② 필요 시 TUN으로 프로세스·UDP 경로를 Clash에 태움 → ③ mihomo에서 telegram.org·t.me 등 접미를 전용 정책 그룹으로 묶음 → ④ DNS·fake-ip·DoH 누수 제거 → ⑤ 노드·UDP 품질 교차 검증 순서로 좁히는 것이 재현에 유리합니다. ChatGPT 지역 우회나 Netflix 재생처럼 다른 키워드로 쓰인 글과 섞지 않고, 메신저 축만 따로 실험해 보시길 권합니다.

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