Bluesky·AT 프로토콜 총 타임아웃? 2026년 Clash 분류로 소셜 피드·첫 화면 안정화

Threads·TikTok 글과 무엇이 다른가

Meta·숏폼 글은 대개 알려진 상용 도메인 묶음을 기준으로 규칙을 쌓으면 됩니다. Bluesky·AT 쪽은 연합(federation) 구조 때문에, 같은 앱이라도 내 계정의 PDS·릴레이·서드파티 호스트가 로그에 새로 뜨는 일이 잦습니다. 그래서 “유명 서픽스 몇 줄”만 복붙해 넣기보다 연결 로그에서 본 FQDN으로 행을 좁히는 습관이 더 중요합니다. 지연(ms)보다 서로 다른 출구에 쿠키·TLS 세션이 갈리는 문제가 타임아웃처럼 보이는 경우가 많습니다.

AT·bsky 트래픽을 네 축으로 나누기

실무에서 먼저 그리는 멘탈 모델입니다. 클라이언트·지역·릴리스에 따라 호스트명은 변하므로, 아래는 출발점이며 반드시 본인 환경 로그로 치환하세요.

• 메인 웹·앱 셸: 초기 HTML·JS 번들·라우팅 — 예: bsky.app, 공개 웹 게이트웨이 계열.
• xrpc·JSON API: 피드·프로필·검색 등 JSON — 공개 엔드포인트와 앱 내장 클라이언트가 같은 출구를 타야 세션이 안 꼬입니다.
• 미디어·블롭·CDN: 이미지·짧은 클립·썸네일 — 대역·지터에 민감해 DIRECT와 프록시가 섞이면 “일부만 영원히 로딩”이 됩니다.
• 실시간·동기화: WebSocket·이벤트 스트림·백그라운드 동기화 — 한 번 끊기면 앱이 전체를 다시 그리며 타임아웃처럼 보일 수 있습니다. 장기 연결 패턴은 Character.AI WebSocket 글과 비교해 보세요.

자가 호스팅 PDS를 쓰는 계정은 *.bsky.social 밖의 커스텀 도메인이 API 경로에 등장할 수 있습니다. 그럴 때는 서픽스 규칙보다 로그에서 확인한 단일 DOMAIN 행이 안전합니다.

정책 그룹 설계

디버깅을 쉽게 하려면 한 개의 PROXY에 몰아넣기보다 다음처럼 쪼갭니다.

• Bsky-App: 메인 앱·웹 셸·일반 xrpc 진입점.
• Bsky-Media: 블롭·비디오·이미지 CDN — 안정적·대역이 나은 출구를 쓰는 편이 피드 체감에 유리한 경우가 많습니다.
• Bsky-Realtime(선택): WebSocket·스트림 — 가능하면 앱 그룹과 동일 노드로 맞춰 세션을 통일합니다.

그룹이 많을수록 규칙 순서 관리 부담이 커지므로, 처음에는 Bsky-App과 Bsky-Media 두 개만 두고 증상이 남는 축만 분리해도 됩니다.

Clash 분류 규칙 예시

아래는 예시입니다. 정책 그룹 이름은 구독에 맞게 바꾸고, 행은 로그에서 본 호스트로 교체하세요. 넓은 DOMAIN-SUFFIX는 다른 서비스까지 끌어올 수 있어, 가능하면 구체 호스트로 좁힙니다.

# Illustrative rules — replace policy groups; verify hostnames from your logs
rules:
  - DOMAIN-SUFFIX,bsky.app,Bsky-App
  - DOMAIN-SUFFIX,bsky.social,Bsky-App
  # Add exact API / media hosts observed in your client logs, e.g.:
  # - DOMAIN,public.api.bsky.app,Bsky-App
  # - DOMAIN-SUFFIX,video.bsky.app,Bsky-Media

행이 최종 MATCH나 넓은 GEOIP보다 위에 있는지, RULE-SET 병합 뒤 순서가 뒤집히지 않았는지 확인하세요. 원격 규칙이 오래되면 rule-providers 경로·interval부터 점검합니다.

증상	우선 볼 축
로그인 직후만 실패	OAuth·세션 쿠키 도메인·동일 출구
피드만 비고 검색은 됨	피드 전용 xrpc 호스트·DNS 불일치
미디어만 끊김	블롭 CDN·차단된 릴레이·대역
새 글이 실시간 반영 안 됨	WebSocket·롱 연결·노드 플랩

DNS·fake-ip 정렬

fake-ip를 쓰면 브라우저가 본 주소와 코어의 도메인 규칙 매칭이 어긋나기 쉽습니다. 소셜 앱은 한 화면에 수십 호스트를 동시에 치므로 다음을 순서대로 맞춥니다.

1. TUN 또는 시스템 DNS 위임이 켜져 있는지, 다른 VPN과 DNS만 이중으로 갈라지지 않는지 확인합니다.
2. nameserver와 fallback이 모두 도달 가능한지, 특정 국가 DNS만 쓰다가 CDN 이름 해석이 엇갈리지 않는지 봅니다.
3. 문제가 남으면 DNS·fake-ip 점검 글대로 한 번에 한 변수만 바꿉니다.

노드 선택·WebSocket·피드 프리패치

피드는 짧은 요청이 아주 많이 연쇄합니다. url-test 주기가 너무 짧으면 TLS 세션이 자주 갈려 “전체가 느리다”로 느껴질 수 있어, 체감이 나쁠 때는 고정 프록시나 긴 간격 그룹으로 비교해 보세요. 반대로 미디어만 다른 릴레이로 보내고 API는 다른 노드를 쓰면 리전·인증 상태가 어긋날 수 있어, 처음에는 한 출구로 통일한 뒤 미디어만 분리하는 순서가 안전합니다. 실시간 축은 끊김에 민감하므로 url-test·fallback·tolerance 설정이 과하게 공격적이지 않은지도 함께 봅니다.

모바일 앱 vs 브라우저

앱은 시스템 VPN·배터리 최적화·개별 앱 정책의 영향을 크게 받습니다. 브라우저만 이상하면 확장·보안 DNS를 의심하고, 앱만 이상하면 OS 개인 DNS·절전·백그라운드 제한을 함께 봐야 합니다. 가정망에서 특정 기기만 문제면 LAN·mixed-port로 출구를 맞추거나, 라우터에서 OpenClash로 DNS를 통일하는 방법을 고려하세요. 데스크톱 초기 설정은 Windows, macOS는 Clash Verge Rev를 참고한 뒤 본문 규칙을 얹으면 됩니다.

로그로 검증하기

규칙을 수정한 뒤에는 피드 새로고침·프로필 이동 중 연결 로그에서 매칭된 정책과 목적지 호스트가 기대한 그룹인지 확인합니다. API 호스트가 DIRECT로 남아 있으면 더 구체적인 DOMAIN 행이 필요하거나, 상위 광범위 규칙이 먼저 승리한 것입니다. HTTPS 스니핑을 켠 뒤 핸드셰이크 오류가 나면 Sniffer 제외 글을 참고해 관련 도메인을 단계적으로 제외해 봅니다.

Web 패널·외부 접속 메모

디버깅을 위해 Clash Meta의 external-controller나 내장 Web UI를 열어 두었다면, bind-address·secret·방화벽으로 노출 범위를 제한하세요. 소셜 로딩을 고치려다 관리 포트가 공용망에 열리면 위험이 커집니다.

FAQ

특정 계정만 느리다

해당 계정의 PDS 호스트가 다른 출구를 타거나 DNS가 엇갈린 경우가 많습니다. 로그에서 xrpc 대상 FQDN을 잡아 Bsky-App과 동일 노드로 맞춥니다.

Wi-Fi에서만 깨진다

라우터 DNS·IPv6·캡티브 포털, 또는 분할 터널이 Wi-Fi에만 적용되는지 확인합니다. 동일 프로필이라도 게이트웨이마다 실제 해석 결과가 달라질 수 있습니다.

실무 체크리스트

정리

Bluesky·AT 프로토콜은 “한 서비스”처럼 보여도 웹 셸·xrpc·블롭·실시간이 갈라지는 전형적인 패턴을 보여 줍니다. Meta 소셜·TikTok 글의 미디어·DNS 정렬 원리를 빌리되, 호스트 축을 연합형 bsky 스택에 맞게 좁히면 총 타임아웃과 스피너를 빠르게 줄일 수 있습니다.

Clash를 무료로 내려받고 분류·DNS를 손에 익혀 보세요