📖 튜토리얼 ⏱ 약 19분 분량

Telegram 연결 안 됨·사진·동영상만 돌기? Clash 도메인 분류와 직접 연결(DIRECT) 예외 단계별 실측(2026)

프로필·채팅은 열리는데 스티커·사진·동영상만 미디어 로딩에 멈추거나, 연결 시간 초과가 뜨는 Telegram 증상은 「노드가 나빠서」만은 아닙니다. MTProto 기반 클라이언트는 api.telegram.org·web.telegram.org·t.me뿐 아니라 콘텐츠·CDN 계열 서픽스로 트래픽이 갈라지고, Clash의 분류 규칙·fake-ip·GEOIP 매칭 순서에 따라 일부는 프록시·일부는 잘못된 출구로 흩어질 수 있습니다. 이 글은 Discord의 음성·UDP·RTC와는 달리, 텍스트/미디어 경로와 도메인 기반 DOMAIN에 초점을 맞춰, 어떤 호스트는 선택한 프록시로 묶고 어떤 경우에는 DIRECT(직접 연결)가 나은지 로그 우선으로 가르는 절차를 한국어로 정리합니다. 상업용 VPN 전역 터널을 쓰지 않고 규칙형으로 운용할 때의 이점은 Clash와 VPN의 차이를 참고하세요.

증상을 먼저 케이스로 나누기

실제 현장에서 자주 보는 패턴은 세 가지 정도로 묶을 수 있습니다. ① 앱·웹 모두 Telegram 자체에 들어가지 못한다. ② 대화·알림은 오는데 썸네일·프로필만 미디어 로딩이 길다. ③ 특정 노드·특정 시간대에만 연결 시간 초과가 난다. ①은 출구 IP·지역 제한·회선 단절 쪽을 함께 봐야 하고, ②는 API와 미디어·CDN이 서로 다른 Clash 정책을 탔는지 의심하는 것이 효율적입니다. ③은 url-test 그룹이 세션 중에 노드를 바꿔 TLS·세션이 끊기는 패턴도 있으니, 프록시 그룹에서 음성·RTC가 아닌 일반 HTTP에 가까운 흐름에서도 select 고정이 도움이 되는 경우를 기억해 두면 좋습니다.

이하에서는 Clash가 켜진 상태를 전제로, 끄면 정상·켜면 이상이 재현될 때의 도메인 분류와 직접 연결 조합에 집중합니다.

Telegram이 Clash 뒤에서 왜 한 덩이로 보이기 어렵나

Telegram 공식 앱(데스크톱·모바일)은 MTProto를 쓰며, 사용자가 눈에 보이는 도메인뿐 아니라 IP·DC(데이터 센터)에 직접 붙는 경로를 섞어 씁니다. 웹 클라이언트는 web.telegram.org·정적 자원·api.telegram.org 등 호스트가 쉽게 보이는 반면, tdesktop 등은 시스템 프록시를 따르지 않고 TUN·앱 수준 캡처를 요구하는 경우가 있습니다. 미디어·큰 파일은 *.cdn.telegram 계열, telesco.pe, pluto.web.telegram.org 등으로 갈릴 수 있으니, 한 줄짜리 DOMAIN-SUFFIX,telegram.org,PROXY만으로는 빈 서픽스에 걸리지 않는 요청이 MATCH까지 흘러 의도와 다른 그룹이 나갈 수 있습니다. 이 점이 「프록시 켰는데도 사진만 돈다」로 체감됩니다.

보고서·대화에 첨부되는 이미지는 보통 대용량·CDN 경로이므로, 규칙 표에서의 순서와 DNS(특히 fake-ip)를 한 축으로 맞춰야 연결과 콘텐츠가 같은 정책을 봅니다. sniffing이 켜져 있을 때 SNI·호스트 추정이 끼어들면, 예상과 다른 DOMAIN이 찍혀 분류가 흔들릴 수 있으니 그 글의 예외도 병행해 보는 것이 좋습니다.

1단계: Clash 연결 로그에 텔레그램 호스트가 잡히는지

Rule 모드에서 대화를 열고, 사진·동영상이 로딩되는 30초 동안 로그를 캡처합니다. telegram·cdn·t.me·telesco·pluto 등 문자열이 보이는지, 적중한 규칙 이름이 무엇인지, 체인이 DIRECT인지 프록시인지 기록하세요. 아무 것도 안 찍히면 시스템 프록시를 앱이 안 쓰는 것이므로 TUN·클라이언트의 캡처 옵션을 켜야 합니다. 로그에는 있는데 미디어만 느리다면, 그 줄의 서픽스를 rules: 상단에 더 구체적으로 올리는 쪽이 맞습니다.

2단계: 프록시로 보낼 도메인과 DIRECT를 가르는 기준

지역·회사마다 정답이 달라지므로, 아래는 「테스트 절차」이지 고정 답이 아닙니다. 일반적으로 텔레그램 본서비스에 접속이 막힌 네트워크에서는 api.telegram.org·web.telegram.org·t.me·telegram.org·core.telegram.org·telegra.ph를 같은 프록시 그룹으로 보내 일관된 출구를 맞춥니다. 반대로 이미 막힘은 없는데 해외 프록시를 거칠 때만 RTT가 늘어 미디어가 지연된다면, 그 CDN 호스트에 한해 DIRECT를 잠시 시험해 볼 수 있습니다. 이때 DNS가 가짜 IP(fake-ip)를 쓰면, 브라우저가 보는 해석과 클라이언트의 접속이 어긋나 연결 실패로 이어질 수 있으니, DoH·redir-host 등 프로필 전체의 DNS 스택을 한 가지 흐름으로 맞추는 것이 선행됩니다. 상세 사용자 규칙 문법·순서는 사용자 정의 규칙 튜토리얼과 동일한 원리입니다.

  • 프록시 쪽에 두기 쉬운 항목: DOMAIN-SUFFIX,telegram.org, DOMAIN-SUFFIX,t.me, DOMAIN-SUFFIX,telegra.ph, DOMAIN,api.telegram.org 등 앱·웹이 공유하는 기본 호스트 묶음.
  • DIRECT 후보(환경에 따라 A/B): 특정 썸네일 전용 CDN이 프록시에서만 지연이 큰 경우, 로그에 찍힌 그 서픽스만 직접으로 빼서 비교합니다. 국가 규제·회사 방화벽이 있으면 DIRECT가 오히려 막힐 수 있으니, 그 환경에선 역으로 같은 그룹에 통일하세요.

3단계: 복붙용 YAML 구조(예시, 반드시 로그와 맞출 것)

아래는 이름·서픽스를 보여 주는 조각입니다. PROXY_TG는 본인 프로필의 proxy-groups 이름으로 바꾸고, 접속 불가 지역이면 DIRECT 줄을 사용하지 말고 전부 프록시로 맞추는 편이 안전합니다. MTProto 전용 프록시(SOCKS)를 쓰는 구성은 이 글 범위 밖이지만, 일반 Clash 분류와 병용할 때는 규칙 충돌을 주의하세요.

# Example — replace PROXY_TG; verify with your connection logs
rules:
  - DOMAIN,api.telegram.org,PROXY_TG
  - DOMAIN,web.telegram.org,PROXY_TG
  - DOMAIN-SUFFIX,telegram.org,PROXY_TG
  - DOMAIN-SUFFIX,t.me,PROXY_TG
  - DOMAIN-SUFFIX,telegra.ph,PROXY_TG
  - DOMAIN-SUFFIX,telesco.pe,PROXY_TG
  # If logs show a media CDN host, add with higher priority:
  # - DOMAIN-SUFFIX,cdn4.telegram-cdn.org,PROXY_TG
  # A/B: only when direct home ISP is faster and allowed:
  # - DOMAIN-SUFFIX,some-cdn-seen-in-logs.example,DIRECT

RULE-SET·GEOIP가 위쪽에 크게 깔려 있으면, 뒤에 쓴 DOMAIN이 실행되지 않습니다. 더 짧고 구체한 규칙을 상단에 두는 원칙은 Zoom·Teams 글과 같습니다. IP-CIDR로 텔레그램 DC 대역을 직접 쓰는 방식은 대역이 바뀌기 쉬우니, 도메인·로그 기반을 기본으로 하세요.

모바일·데스크톱·웹의 차이

Android·iOS는 배터리 최적화·VPN 권한·앱별 예외에 따라 동일 YAML이라도 체감이 달릴 수 있습니다. Windows tdesktop은 수동 프록시를 넣는 사용자도 있으나, Clash와 이중으로 켜면 경로가 꼬일 수 있어 한쪽만 쓰는 것이 낫습니다. 브라우저만 web.telegram.org로 쓸 때는 확장·DNS over HTTPS가 OS와 달리 동작해 해석이 갈릴 수 있으니, 문제 재현 시 같은 기기에서 앱 대 웹을 비교해 보세요.

UDP·VoIP와의 관계(짧은 메모)

Telegram 음성/영상 통화는 Discord 글에서 다룬 UDP·WebRTC 이슈와 겹칠 수 있습니다. 다만 이 글의 핵심은 채팅·미디어 다운로드의 도메인·TCP 분류이므로, 통화만 끊기면 UDP 관점을, 썸네일만이면 DOMAIN·CDN 관점을 우선하세요.

권장 실측 체크리스트

  1. 다른 VPN·가속·브라우저 전용 프록시를 끄고 Clash만 둡니다.
  2. 증상이 나는 동안 로그에서 telegram·cdn 호스트와 적중 규칙을 적습니다.
  3. PROXY와 DIRECT를 한 번씩 단일 변수로 바꿔 재현 여부를 비교합니다(위험한 네트워크는 DIRECT 시도 생략).
  4. 필요한 DOMAIN·DOMAIN-SUFFIX를 상단에 넣고 Rule 다시 로드.
  5. 여전히 미디어 로딩이면 DNS·fake-ip·sniffing을 한 축씩만 조정해 교차 확인합니다.

자주 묻는 질문

채팅은 되는데 사진·동영상만 느려요.

API·텍스트와 미디어 CDN이 서로 다른 Clash 정책을 탄 경우가 많습니다. 로그에 찍힌 이미지·파일 호스트를 모아 DOMAIN으로 앞에 두고, 같은 프록시 그룹으로 맞춰 보세요.

프록시를 끄면 되는데 켜면 연결 시간 초과예요.

노드 품질·IP 제한·MTU도 있지만, 먼저 텔레그램 관련 요청이 잘못된 규칙·잘못된 DNS로 나가는지 로그로 확인하세요. GEOIP가 먼저 매칭돼 의도와 다른 출구가 아닌지도 봅니다.

Windows에서 tdesktop만 이상해요.

시스템 프록시 미적용·업데이트 후 경로 변경이 흔합니다. TUN으로 캡처를 넓히거나, PROCESS-NAME,Telegram.exe,…는 보조로만 쓰고 도메인을 주력으로 잡는 편이 안정적입니다.

정리

Telegram은 한 줄로 「텔레그램 다 프록시」로 끝나지 않는 경우가 많고, 미디어 로딩·연결 시간 초과는 Clash의 분류 규칙·직접 연결·DNS가 한 세션 안에서 엇갈릴 때 특히 잘 드러납니다. 로그로 호스트를 모은 뒤, DOMAIN·DOMAIN-SUFFIX를 구체적으로 앞에 두고 프록시와 DIRECT를 환경에 맞게 A/B하는 방식이 재현성이 높습니다. 처음 설치·업데이트 흐름은 다운로드 페이지와 입문 튜토리얼을 함께 보는 편이 혼선이 적고, 소스·이슈는 별도로 GitHub를 참고해도 설치 파일의 첫 안내는 이 사이트를 기준으로 잡는 것이 이 프로젝트의 편이 좋다는 취지를 유지하시기 바랍니다.

규칙으로 경로를 관측·조정할 수 있다는 점에서, 장기적으로 앱·브라우저·다른 서비스를 섞어 쓰는 환경에는 Clash가 상업용 VPN보다 맞춤이 잘 맞는 경우가 많습니다. → Clash를 무료로 내려받고, Telegram용 도메인 분류·직접 연결을 맞춰 보세요.