1. 증상을 먼저 나누기: 연결·동기화·CDN은 다른 축입니다

사용자 입장에서는 모두 “텔레그램이 느리거나 끊긴다”로 느껴지지만, 관찰 포인트는 다릅니다. 첫째, 앱 상단이나 설정에 연결 중 상태가 길게 유지되고 로그인·채팅 목록이 갱신되지 않는 경우입니다. 둘째, 목록은 뜨는데 특정 대화의 미디어·스티커·프로필 사진이 계속 로딩만 하는 경우입니다. 셋째, 데스크톱은 되는데 모바일만 불안정하거나 그 반대인 경우입니다. 넷째, 노드를 바꾸면 즉시 나아지고, 다른 노드에서는 항상 같은 패턴이 반복되는 경우입니다. 각각 걸리는 호스트 묶음과 전송 방식이 조금씩 다르므로, 한 번에 “텔레그램 전부 PROXY” 로 덮기보다 연결 로그에 찍힌 도메인 을 근거로 나누는 편이 안전합니다.

구독 YAML 을 아직 익숙하게 다루지 않는다면 구독 가져오기 튜토리얼에서 프로필을 먼저 안정화한 뒤 이 글의 분류 단계로 넘어오는 편이 좋습니다.

2. MTProto·CDN·WebSocket을 왜 구분해 보나요?

MTProto 는 Telegram 이 서버와 주고받는 핵심 프로토콜 계층으로 이해하면 됩니다. 클라이언트는 데이터 센터에 맞춰 TCP 연결을 열고, 그 위에서 채팅·채널·동기화 상태를 유지합니다. 반면 스티커 팩·이미지·큰 파일·앱 업데이트 번들은 CDN 엣지에서 내려오는 경우가 많아, 핵심 세션과 다른 호스트 이름·경로를 가집니다. 웹 클라이언트나 일부 보조 기능은 HTTPS 와 WebSocket 을 함께 쓰기도 합니다. 공항 구독의 광범위 규칙이 CDN 접미사를 DIRECT 로 보내고 핵심 API 만 프록시를 타면, 화면은 “반쯤” 뜨고 연결 실패 가 반복되는 것처럼 보이기도 합니다. 반대로 모든 트래픽을 무조건 먼 노드로 몰면 지연이 커져 체감이 나빠질 수 있습니다. 그래서 “같은 앱이라도 목적별로 정책을 나누고, 로그로 검증한다”는 접근이 중요합니다.

Clash 계열은 버전과 코어에 따라 TCP·UDP·TUN 처리 세부가 다릅니다. 이 글은 특정 필드 이름을 강제하지 않고, Mihomo 최신 문서와 GUI 설명을 함께 보는 전제에서 공통 원리만 짚습니다.

3. 권장 점검 순서

  1. Clash 가 켜져 있는지, 시스템 프록시 인지 TUN 인지 기록합니다.
  2. 실시간 연결 목록에서 telegram·t.me·cdn·core 등 관련 호스트가 기대한 정책 그룹으로 나가는지, DIRECT 로 새는지 확인합니다.
  3. 앱을 완전히 종료했다가 다시 연 뒤, 로그인 직후·채널·대화 진입 직후에 새로 뜨는 호스트를 각각 비교합니다.
  4. fake-ip 사용 여부와 DNS 해석 정책을 확인하고, 필요하면 핵심 접미사에 nameserver-policy 를 둡니다.
  5. 로그에서 본 호스트를 DOMAIN-SUFFIX 규칙으로 올리고, 공급자 규칙·로컬 규칙의 순서 충돌을 정리합니다.
  6. 여전히 핵심 연결이 빠지면 TUN 전환, 다른 상시 VPN 종료, 방화벽 예외를 순서대로 시험합니다.

4. Telegram Desktop과 모바일이 프록시를 타는 경로

데스크톱 앱은 많은 경우 시스템 프록시를 따르지만, 일부 네이티브 모듈이나 백그라운드 다운로더는 예외가 있어 DIRECT 로 나가기도 합니다. 브라우저에서 웹 텔레그램 은 되는데 앱만 연결 중 에 머무르면 이런 경로 차이를 의심하세요. 이때 TUN 모드를 켜면 라우팅 계층에서 잡혀 동일 출구로 묶이기 쉽습니다. 다만 다른 상시 VPN 과 동시에 켜면 어댑터 충돌이 생길 수 있으니, 한 번에 하나의 터널만 남기고 다시 테스트하세요.

모바일 iOS·Android 는 앱별로 시스템 VPN 프로필이나 TUN 기반 클라이언트를 쓰는 경우가 많습니다. PC 와 동일한 구독을 쓰더라도, 플랫폼마다 “어떤 트래픽이 코어에 올라오는지”가 다를 수 있으므로, 증상이 기기별로 갈리면 그 기기의 연결 로그를 따로 모으는 것이 좋습니다.

5. DNS·fake-ip: 규칙과 어긋나면 동기화가 멈춘 것처럼 보입니다

fake-ip 는 체감 지연을 줄이는 데 도움이 될 수 있지만, 해석 결과와 실제 연결 목적지가 어긋나면 TLS 핸드셰이크가 반복되고 대화·미디어 동기화는 시작조차 못 하는 것처럼 보입니다. 특히 CDN 분류 가 끼어 있는 서비스에서 서브도메인마다 다른 엣지로 붙는 패턴이면 증상이 두드러집니다.

상위 DNS 가 신뢰 가능하고 Clash 에서 도달 가능한지 먼저 확인한 뒤, telegram.org·t.me 등 핵심 접미사에 별도 해석 정책을 두는 방식을 검토하세요. 필드 이름은 Mihomo 버전에 따라 다를 수 있으니 최신 문서와 예제를 함께 보는 것이 안전합니다. 규칙을 고친 뒤에는 OS DNS 캐시를 비우거나 앱을 완전히 종료했다가 다시 열어 이전 세션이 남지 않게 하는 것도 도움이 됩니다.

6. 도메인 수집: 연결 패널이 최우선 증거입니다

인터넷에 떠도는 “완성된 텔레그램 도메인 목록”은 배포 시점과 지역·ISP 에 따라 빠르게 달라질 수 있습니다. 그래서 이 글은 고정 목록을 외우게 하기보다, 본인 기기 세션에서 실제로 붙는 호스트 를 모으는 절차를 권장합니다.

Clash Verge Rev 등 GUI 에서 실시간 연결을 연 뒤 Telegram 에서 앱을 재시작하고, 채팅·채널·설정·스티커 저장소를 열었다 닫았다를 반복합니다. telegram.org·t.me·telegram.me 외에 tdesktop.com·telesco.pe 등 데스크톱·CDN 계열, web.telegram.org 등 웹 관련 호스트가 보이는지 메모합니다. 실패한 연결(타임아웃·리셋)의 호스트를 우선적으로 규칙에 올리면 체감이 가장 큽니다.

텔레그램 프록시 문제를 줄이려면 “추측으로 노드만 바꾸기”보다, 로그에 찍힌 문자열을 그대로 복사해 두었다가 규칙에 반영하는 습관이 더 빠릅니다.

7. 규칙에 올리기 전 체크리스트

아래 표는 사고를 돕는 틀일 뿐이며, 실제 이름과 개수는 반드시 연결 로그로 검증해야 합니다.

구분예시 방향메모
공식·링크·웹telegram.org·t.me·telegram.me로그인·딥링크·공지 흐름과 함께 묶이는지 확인합니다.
데스크톱 배포desktop.telegram.org·tdesktop.com업데이트·설치 패키지가 같은 출구인지 봅니다.
CDN·정적 자산cdn*·telesco.pe 등스티커·미디어·대용량이 MTProto 와 다른 경로인지 확인합니다.
웹·보조web.telegram.org 등WebSocket·HTTPS가 따로 보이면 묶어서 점검합니다.

8. 규칙 예시 (정책 그룹 이름은 교체)

# Example only — replace PROXY with your policy group name
rules:
  - DOMAIN-SUFFIX,telegram.org,PROXY
  - DOMAIN-SUFFIX,t.me,PROXY
  - DOMAIN-SUFFIX,telegram.me,PROXY
  - DOMAIN-SUFFIX,tdesktop.com,PROXY
  - DOMAIN-SUFFIX,telesco.pe,PROXY
  - DOMAIN-SUFFIX,web.telegram.org,PROXY

DOMAIN-KEYWORD,telegram 는 편하지만 오탐이 생기기 쉬우니 과도하게 쓰지 말고, 로그에 근거해 접미사를 좁히세요. 업데이트만 특정 노드로 보내고 채팅은 지연이 적은 다른 그룹으로 보내고 싶다면 정책 그룹을 두 개로 나누어 디버깅하기 쉽게 만들 수 있습니다. 다만 실제 운영에서는 “한 세션 안에서 호스트가 서로 다른 출구를 보면” 인증·쿠키·지역 판정이 꼬일 수 있으니, 먼저 같은 출구로 묶인 상태에서 안정화 한 뒤 세분화하는 순서를 권합니다.

Telegram 측 호스트 명은 시기에 따라 바뀔 수 있으므로, 위 예시는 출발점으로만 두고 본인 세션 기준으로 덮어쓰는 것이 좋습니다.

9. MTProto와 IP·데이터센터: 규칙만으로 안 될 때

일부 클라이언트는 도메인이 아닌 IP 대역에 직접 붙는 흐름이 있어, DOMAIN-SUFFIX 만으로는 잡히지 않을 수 있습니다. 이때는 연결 로그에 찍힌 목적지 IP 가 코어를 통과하는지, DIRECT 로 새는지를 먼저 확인하세요. TUN 모드에서는 이런 흐름이 상대적으로 잘 잡히는 경우가 많지만, 환경마다 다릅니다.

공항 노드가 특정 포트나 긴 세션을 제한하면 증상이 노드에만 종속되어 나타나기도 합니다. 이때는 규칙보다 노드 제약 이 원인입니다. 전송 계층 특성은 프로토콜 비교 글을 참고해 보조 근거를 얻을 수 있습니다.

10. GEOIP·대륙 직결 규칙과의 충돌

공항 구독에 GEOIP,CN,DIRECT 같은 광범위 규칙이 있으면, 일부 CDN 엣지가 의도치 않게 직결로 보내져 “한국 노드를 썼는데도 미디어만 안 받아진다”는 패턴이 납니다. 이럴 때는 Telegram 관련 블록을 규칙 상단에 두거나, 충돌하는 공급자 규칙 뒤에 로컬 덮어쓰기가 먹히도록 순서를 재확인하세요.

구독이 업데이트되며 예전에 넣어 둔 로컬 규칙이 뒤로 밀리는 경우도 흔합니다. “텔레그램 전용 블록”을 파일 상단에 두고 주기적으로 순서를 점검하면 재발을 줄일 수 있습니다.

11. GUI 워크플로: Clash Verge Rev

연결 패널에서 호스트 문자열을 필터링하면 잘못된 DIRECT 를 빠르게 찾을 수 있습니다. 첫 설치와 구독 흐름은 Clash Verge Rev 초보자 가이드를 따르세요. 대용량 CDN 분류 패턴을 이미 다뤄본 적이 있다면 Steam 상점·CDN 분류 가이드와 로그 읽는 습관을 나란히 두면 학습 곡선이 줄어듭니다.

12. 그래도 안 될 때: 일반 트러블슈팅과의 교차

포트 충돌·구독 파싱 오류·코어 업데이트 실패 같은 주제는 앱별 글보다 공통 절차가 빠릅니다. Clash 일반 트러블슈팅 가이드에서 7890 포트·프로필 유효성·TUN 권한을 먼저 확인한 뒤, 이 글의 Telegram 전용 단계로 돌아오세요.

13. 정리: 로그 근거를 한 층씩 쌓기

Telegram Desktop 과 모바일에서 연결 중 만 길게 뜨거나 연결 실패 가 반복되는 현상은 단일 스위치가 아니라 프록시 모드·DNS·규칙 순서·MTProto·CDN·WebSocket·노드 품질 이 겹친 결과인 경우가 많습니다. 이 글의 순서대로 연결 로그 증거를 남기면 불필요한 노드 순환과 잘못된 DIRECT 를 빠르게 줄일 수 있습니다.

설정 파일을 매번 직접 고치기보다 Mihomo 를 내장한 공식 클라이언트에서 로그·업데이트·프로필 전환을 한 화면에서 처리하는 편이 운영 부담이 적습니다. 범용 프록시 도구와 비교해도, 구독·분류·연결 기록이 함께 있으면 “일부 호스트만 빠진다”는 증상을 빠르게 좁힐 수 있습니다. → Clash 를 무료로 내려받고 Telegram 세션을 같은 출구로 묶어 보세요