Bluesky 與 AT 協定總逾時？2026 年用 Clash 分流穩住社交載入
在 2026 年，去中心化社交與「X 替代品」討論裡，Bluesky 與其底層 AT Protocol 仍常出現在科技與網路圈。實際使用時，讀者最常抱怨的不是「單一頁面打不開」，而是首屏轉久、資訊流往下滑幾則就卡住、預覽圖與短影片片段一直轉圈、或手機客戶端在背景回來之後要等很久才同步。這和傳統單一超大後台、所有流量走幾條品牌域名的產品不同：AT 協定牽涉帳戶倉庫（PDS）與中繼、索引、內容與信號等多組主機名，再加上現代客戶端常見的 WebSocket 與多段 CDN 媒體，路徑只要有一段走錯節點、被泛用的 GEOIP 提前截走，或 DNS／fake-ip 和實連線不一致，體感就會變成「bsky 一直在逾時」。本篇以 Clash（含常見 Meta／Mihomo 系核心）說明如何把主站、公開 API、媒體與長連線拆進可維護的策略組，用規則順序與日誌把出口對齊；並主動與站內 Threads、Instagram 分流專文、TikTok 分流專文區隔——Meta 系是集中式圖文與 Reels 堆疊、TikTok 偏短影音與直播，Bluesky 則是 AT 帳戶＋PDS 與公開索引的多跳路徑，硬套前兩者域名表，往往只能修一半。
為什麼「只代理 bsky 首頁」常修不好
許多從傳統社群搬過來的使用者，會直覺寫一條 DOMAIN-SUFFIX,bsky.app 就結束。問題在於：瀏覽器或官方客戶端載入畫面時，除開您看得見的網站殼，還會在背後打公開 XRPC 端點、媒體與圖像 CDN、以及維持時間軸與通知的長連線。若帳戶位於第三方或自架 PDS，還可能出現子網域分散、識別服務與內容取回分散在不同地區的狀況。您若把上述流量一股腦丟到「延遲漂亮但丟包敏感」的節點，或讓少數幾條關鍵主機名意外 DIRECT 到不佳的 ISP 路徑，外觀就會是靜態文字偶爾能出現、圖卻卡死，或能滑兩則、貼上影片就掛。
和 長影音解鎖那種「一條觀測大影片串流夠不夠穩」不同，社交貼文列表是大量小物件與高頻互動交錯，對 TLS 握手、首包、DNS 重試 特別敏感。當 Clash 的分流規則沒有把 Bluesky 相關主機一視同仁地導到同類策略，或規則集合併後把您的自訂列擠到永遠命不中，AT Protocol 的客戶端就會不斷重試、逾時、再重試——使用者看到的就是 bsky 整體「總是逾時」。
- 多主機、多職能：同一個畫面可能同時觸及網站殼、API、快取與媒體，不必共用同一 FQDN。
- 帳戶可外置：PDS 讓「跟誰要貼文」變成路由問題，而不是單一公司後台帳單一出口。
- 長連線：更新資訊流、通知、串流類功能依賴能維持的通道，對路徑切換比單次 GET 更敏感。
心智模型
把 AT Protocol 想成多站協作：先確保 DNS 解析與 fake-ip 不打架，再依職能（文字／API／媒體／長連線）拆 策略組，最後才微調單一節點城市。順序顛倒時，看起來像「Clash 壞了」，其實是命中規則與實際連線不對位。
主站、API、媒體與 WebSocket：四層切開看
實務上，您不必背下所有可能變動的主機名，但要在日誌中辨識出四種行為層次，並在 Clash 裡給它們一致的出口敘事。下列中文說明採用工程常見的職能分類，實機請以客戶端實際連線為準。
| 層次 | 職能（概念） | 與「逾時」的關係 |
|---|---|---|
| 主站殼層 | 帳戶介面、網站資源、版本化靜態檔 | 影響首屏是否立刻可互動，常被誤以為「全站掛了」 |
| 公開 API 層 | XRPC、與帳戶、時間軸、社交圖有關的 JSON 交換 | 小請求多、重試多；出口抖動大時像「連線不穩」 |
| 媒體層 | 圖像、短影片、預覽圖、片段式傳遞 | 高度依賴 CDN 串接，一段走錯就整排縮圖轉圈 |
| 信號層 | WebSocket 等長連線、即時性更新 | 比短連線更怕中間人式策略切換與不友善的商業節點 |
在設定策略組時，可為上述層次各配一個可讀的組名（例如從寬鬆到細：BSKY-GENERAL 或依您訂閱自訂），並在健康檢查上偏向延遲與小封包體感，而不是只看大檔下載。若與 體育直播大流量文 相比，社交資訊流更在意大量小型 HTTPS 的完成時間分佈，而不是單一 Mbps 曲線上的峰值。
PDS 與聯邦：日誌比靜態表可靠
AT Protocol 的設計讓帳戶與內容不必綁在單一廠商：您可能關注的人分散在不同 PDS。這帶來一個實務後果：任務兩週前能用的靜態域名表，未必覆蓋今天某一則討論貼的實際取回主機。更穩妥的做法是：在 Clash 先維持寬鬆、可驗證的基底規則，再用連線日誌補釘，而不是在社群貼一張幾十行的表就永不更新。
若您已讀 GeoIP 與 mmdb 修復專文，會直覺想到用 GEOIP 作安全網；但在多國關注者的場景，過早命中 GEOIP 有時反會把少數幾條關鍵 PDS 交握送往非預期出口。實務上建議讓 已知的 bsky 生態關聯子網或從日誌抄寫的目標主機擺在 GEOIP 與寬泛 MATCH 之前，並在調整後用同一客戶端、同一帳戶劃兩則、滑十則的固定流程自測。這與 TikTok 分流 裡靠多子域與直播長連線的思維相鄰，但 Bluesky 的「跟誰要資料」更社交圖與帳戶分佈導向，不要混用兩邊的列表。
不要長期用 Global 掩蓋分組問題
把模式切到 Global 若立刻變順，幾乎可肯定問題在規則命中或 DNS，不是「bsky 本身壞了」。請回到 Rule 模式，讓 AT Protocol 的長連線與 HTTPS 有可預測的命中敘事。長期 Global 也會讓本機其餘流量變得難以除錯。
規則順序：先具體、後寬泛
在 Clash 的 Rule 模式下，順序是真相。針對 Bluesky／bsky 相關流量，一個可讀的骨架通常是：
- 先放與服務相關的明確
DOMAIN／DOMAIN-SUFFIX或從日誌抄寫的單點主機（需維護時就更新）。 - 再處理內部網路、家戶直連、本機迴圈，避免測通訊卻測了代理而誤判。
- 讓寬泛的
GEOIP、IP-CIDR或訂閱的巨型規則集在不會越俎代庖的位置。 - 最後才是
MATCH接預設策略，並確認預設策略不是您不想全天使用的出口。
若您有使用遠端規則合併，建議參考 Mixin 與遠端自訂規則專文，確認本機的「Bluesky 專用列」在合併後的實際位置。常見的故障不是規則寫錯，而是合併後從此命不中。
# Illustrative rules — replace PROXY-LOWLAT / PROXY-STABLE with your policy group names; verify on device
rules:
- DOMAIN-SUFFIX,bsky.app,PROXY-STABLE
- DOMAIN-SUFFIX,bsky.network,PROXY-STABLE
- DOMAIN,public.api.bsky.app,PROXY-STABLE
- DOMAIN-KEYWORD,bsky,PROXY-STABLE
- GEOIP,CN,DIRECT
- MATCH,PROXY-LOWLAT
此段純屬示意：實網中主機名、分支與您帳戶的 PDS 分佈，一律以您裝置上即時日誌優先。把 KEYWORD 開太寬可能誤傷無關 bsky 字樣的網站，上線前請在瀏覽幾十個常去網站後再決定範圍。
DNS、fake-ip 與「連了卻沒內容」
當靜態頁有框架、內文卻永遠載不出時，常是 DNS 解析階段和實際出口脫節。若 fake-ip 與客戶端行為不協調，可能出現少數 WebSocket 在握手層就失敗的樣子。可與 DNS 與 fake-ip 排查專文 併讀，並採用一次只改一個變因的節奏：先讓 DoH／本機解析穩定，再動假 IP 相關選項。許多讀者誤以為 AT Protocol 與 bsky 客戶端不支援在代理環境使用，其實更常見是解析與規則兩層敘事打架。
建議的除錯順序
- 在
Rule模式與可重現操作下（打開、下滑、重載）採集一輪日誌，記錄主機名、策略、成敗。 - 把 反覆出現的逾時主機寫成高優先序的明確列，目標策略與同屏其他 bsky 流量盡量一致。
- 關掉會誤攔 WebSocket 的過激廣告／追蹤清單一輪交叉測（若您有匯入）。
- 最後再微調節點與地區，而不是一開始就換十個城市。
與 Threads、TikTok 專文的分工
站內 Meta 系 Threads、Instagram 分流文 處理的是 instagram.com、threads.net 與相關 CDN、Graph 的單一公司生態內多域名，語境是集中式圖文與 Reels。TikTok 文 則偏短影音、直播與驗證子域。本文聚焦 Bluesky、bsky 與 AT Protocol 帶來的聯邦式多跳路徑，避免三篇文章關鍵字彼此搶同一句話。若您同時是重度短影音用戶，可各取一篇當主修、其他當參考，而不要在同一 Clash 設定裡用單一巨型域名表打全部場景。
合規與帳戶條款
本文僅討論您自有裝置上，如何讓 Bluesky 客戶端與 AT Protocol 相關流量在技術上更穩定地抵達、返回。請遵守服務條款、當地法規與您所屬機構的網路政策。若產品方明文限制某類網路工具，以官方為準。工程上能幫助您的，是透明日誌與可回滾的規則，而不是違反契約的「捷徑」。
實務檢查清單
- 在
Rule模式與固定操作路徑下，抓至少一則完整逾時樣本日誌。 - 把 bsky 相關列放在寬泛
GEOIP之前，合併後再檢查一次實際順序。 - 讓 主站、API、媒體、WebSocket 一類的流量策略敘事一致，減少邊邊角角命不中。
- 掃一輪 DNS 與 fake-ip 設定，與 專文 的建議比對。
- 節點層面先求小請求穩定，再求峰值頻寬；並保留一鍵還原的 YAML 副本。
從可維護的客戶端開始
當您能把「哪條 bsky 相關主機命中哪個策略、DNS 有沒有跟著跑」敘事交代清楚，Clash 就能長期當 AT Protocol 社交的可觀測層，而不只是臨時開關。