Bluesky／AT プロトコル（bsky）でタイムアウトばかり？2026 年、Clash の分流でソーシャル表示とフィード取得を支える

AT プロトは「1 本の graph.facebook」ではない

中央集約型の大手ソーシャルと違い、AT プロトコルの利用体験は、多くの場合表向きの bsky ドメイン以外に、利用者のレコード置き場（PDS: Personal Data Server）やリレー、アプリ閲覧用のビュー層へと、接続名が分岐します。粗く PROXY に一括しつつ、巨大な GEOIP ブロックの上側で一部だけ DIRECT に戻る、あるいは adblock 的な購読ルールに REJECT が当たる、といった時に、HTTPS の表層だけは生きても、WSS や大きい静的オブジェクトの取得が遅延し、「全体がタイムアウトに見える」が起き得ます。ここに対する方針は、禁止解除のレシピではなく、ログ上の SNI ／ホスト名を頼りに、一貫した「Bluesky 用バケット」を用意することです。

コミュニティ内では bsky という短い表記でホスト名が語られることも多いのですが、バージョンアップで新しい接尾辞が増減し得るため、本稿に載せる DOMAIN-SUFFIX はあくまで概念用の仮として読み、自環境の接続表で実名を必ず裏取りしてください。

層状に分かれる接続名のイメージ

次の分類は厳密な仕様図ではなく、Clash ルールの切り出し用の仮枠です。名称は毎回ログで追いかけてください。

• Web／アプリの表層：初期 HTML、スクリプト群、ナビ。多くは bsky.app 系や公式クライアント配布元に寄り、HTTPS の Rule モードで分かりやすい。
• レコード系（PDS まわり）：アカウント、投稿、フォロー関係、レポジトリ取得に関わる API。PDS ホスト名はユーザー／ホスティング事情で個体差が出、+wildcard までは書けない DOMAIN 1 行足しが有効な場面がある。
• メディア・CDN：大きい画像・動画、サムネイル、埋め込み。別 ASN のエッジにだけ向くと、首屏のカバーだけ永遠に出ない、という偏りが生じやすい。
• WebSocket 系：フロントのライブ性を支える 長めの接続。プロキシ互換、TUN キャプチャ、UDP／QUIC の扱いと束ね方がズレると、表層は開いても「更新だけ遅延」に見えがち。

症状で読み分ける：首屏、フィード、PDS だけ、WSS だけ

切り分けのヒント例です。万能ではないので、併せてコアのログ行を抜粋して比較してください。

• 文字と UI 枠は出るのに、画像だけ円が回る：表層 HTML とメディア CDN の出口差。DNS 応答先とルール上の DOMAIN のすれ違いも併疑。
• 既読分は来るのに、新着や通知だけ遅い：ウォーターフロント的な 更新用 WS や、購読先の PDS への往復が、粗い GEOIP 行に飲まれる、などのパターン。
• 自宅ブロードカスタの投稿取得だけ失敗：一部の PDS ホストが、グローバルルールの想定外に残る。狭い DOMAIN を個別に足す方が安全。
• モバイルブラウザはマシで、専用アプリだけ不調：TUN 未使用・システムプロキシ未解釈。Android は アプリ別プロキシと併せて考える価値があります。

分流ルールと順序：DOMAIN を GEOIP より上へ

原則は他稿と同じで、自分の明示行は、巨大な GEOIP や REJECT 購読、最後の MATCH より上。リモートの rule-providers 更新直後に、あなたの上書き行の前後が入替わっていないかを必ず点検します。

下記は 図解用の仮想 YAML です。ポリシー名 BSKY を実在の proxy-group 名に置き換え、ログで得た本物の FQDN へ合わせて拡張・修正してください。

# Illustrative — replace BSKY; verify SNI/hosts in your logs; AT stack evolves
rules:
  - DOMAIN-SUFFIX,bsky.app,BSKY
  - DOMAIN-SUFFIX,bsky.network,BSKY
  - DOMAIN-SUFFIX,bsky.social,BSKY
  - DOMAIN-KEYWORD,atproto,BSKY
  - MATCH,PROXY

atproto を DOMAIN-KEYWORD に寄せるのは、一時的な束ね方としては手早い一方、将来の衝突に注意し、安定期にはログ集計のうえ DOMAIN-SUFFIX へ圧縮するのが安全です。自前の PDS ホストが固定なら、+wildcard や Meta 系 PROCESS-PATH ルール（実装差あり）の可否は、WebSocket 寄りの整理に近い発想で、使えるコマンド名だけ採用し、雰囲気で UDP を全面開放しない、が無難です。

方針	利点	注意
広い DOMAIN-SUFFIX,bsky.*	導入が速い	新ホスト名で取り残し、または他用途ドメインとの衝突
ログ起点の 1 行 DOMAIN	誤マッチを抑えやすい	行数とメンテ工数の増大
rule-providers 合成	本番用と実験用の分離がしやすい	mixin マージ衝突に注意

TUN と WebSocket：同じ「安定グループ」に揃える

システムプロキシだけに頼ると、ネイティブクライアントの WSS や、証明書ピン近傍の挙動が、意図した BSKY 系グループに乗らないことがあります。Clash の TUN でトラフィックを早期に回収し、Rule へ戻すと、PROCESS-NAME 付き（Meta 拡張のある実装）の場合は同じ exe／apk からの発信を一括しやすいです。いきなり UDP を全域許可するより、遅延した接続名をログに取ってから、必要十分な DOMAIN だけ上へ足す手順の方が、事故率は下がりがちです。

DNS、fake-ip、二重スタック

次の違和感は、ノード品質の前に疑う価値があります（詳細は fake-ip 専題 や GeoIP / MMDB 稿と補完しつつ）。

• OS の DNS と Clash の nameserver が分岐し、片方だけが地域最適化された応答 → 表層とメディアで「国の見え方」が揃わない。
• DoH の往路が、意図せず DIRECT に落ち、プロキシ側のドメイン以前に別大陸の A レコードが返る。
• IPv6 優先の OS と、IPv4 前提の DOMAIN ルールの交差。必要なら一時的に ipv6: false 的な層（実装名はクライアント依存）の切り分け。

大まかな作業は、DNS を一系統に揃え、揺れを減らす → ルール行が fake-ip キャッシュと合っているか、の順が扱いやすいです。

ノード：帯域より「一貫性」とフラップ対策

スループット数値は高いのに、短い間隔で url-test 勝者が入れ替わる（フラップ）と、長めの WebSocket や PDS 往復は、ジッターを積み上げたように見えます。間隔 interval や tolerance、fallback 系の立ち位置は、url-test／fallback 専稿の直感を当てはめ、同じ都心／同じ事業者に数分留まる方が、体感が安定しやすい場面があります。

利用規約と法令、そして自責範囲

本記事の内容は、正当な接続品質の改善のための、一般的なネットワーク整理の説明に限ります。各国・各サービス・各 PDS 提供者の利用条件、自組織のセキュリティ方針、職域・学校端末の規則に反する行為、地域偽装や不正、なりすまし、他者への無断中継などは行わないでください。判断に迷う場合は、契約上許容された方法の範囲内にとどめ、専門家の助言を検討してください。

よくある質問

Threads のルールをそのまま流用してよい？

表向きの「ソーシャル」に似た UI でも、ドメイン群と、中央 graph と PDS 分散の違いのため、十分ではないことが多いです。併用したあとも、bsky・PDS 名を 個別にログ裏取りしてください。

表層は速いのに、画像と動画が遅い

まず メディア専有ホストがルール上どこへ当たるか。次に、DNS 応答と TUN キャプチャの漏れ、IPv6 ズレ。いずれも上記 層の考え方に沿うと、原因候補が整理しやすいです。

通知だけ、やたら遅延する

更新系 WebSocket が、粗い GEOIP や REJECT 行、あるいは直結想定の行に巻き込まれていないか。短時間だけ接続表を抜粋し、失敗中の生ホスト名を BSKY と同じグループへ、最小行で足す手順をおすすめします。

チェックリスト

まとめ

2026 年、Bluesky と AT プロトコルは、分散化とオープンなレコード層という点で、従来の大規模集中型 ソーシャルメディア とは違うネットワーク像を与えてくれます。Clash は、その差を層状の 分流ルール と戦略的ノードで扱いやすくする道具です。表層と CDN、PDS、WebSocket のどれが別出口になっているか、ログの一行単位で追い、最終 MATCH 前に 明示的な DOMAIN 行を足すリズムを掴むと、首屏のもっさり感やフィード待ちのストレスを、実務的に下げやすいです。クライアント導入がまだなら、ダウンロードページから取得し、まず Rule モードと疎通を安定させ、上記手順に沿って段階的に拡張する流れをおすすめします。

Clash を無料ダウンロードし、AT 系クライアント周りの経路を整える