Bluesky 与 AT 协议总超时？2026 年用 Clash 分流稳住社交加载
作为去中心化「X 替代品」话题里的常客，Bluesky 与底层 AT 协议（AT Protocol）在 2026 年仍常出现在网络与产品讨论中。实际使用时，网页首屏发灰、信息流长时间转圈、图片与视频已单独超时、或 实时更新迟迟不同步，往往并不是「一个域名没代理」这么单纯——API、静态资源与媒体 CDN、WebSocket 长连会落在不同宿主机上，对时延、抖动与 TLS 握手的敏感度也各不相同。本文用 Clash 把「bsky 系流量」拆到可维护的独立策略组，用分流规则顺序与 DNS / fake-ip 对齐，缓解客户端与浏览器的总超时；并与站内 TikTok 国际版、Threads / Instagram 等文错开产品栈与协议面，专注 AT 与社交图谱这条线。
症状：像「全站断」、其实是多段同时卡住
很多人会把 Bluesky 体验概括成「打开了但什么都没有」：顶部导航出来了，Following 列表空着；或帖子正文有了，头像与外链预览图一直裂图；网页端还可能出现发帖按钮灰掉、时间线不前进。与单纯「墙外网页打不开」不同，AT 协议生态里常见模式是：HTML 壳与若干脚本来自一组主机，JSON 接口与分页走另一组，可播放媒体再指向第三方或专用媒体域。任一段落在高丢包、高 RTT 或被错配的出口，浏览器就会把它算进总超时，你在 UI 上看到的是整页像瘫痪。
与短视频应用相比，Bluesky 不依赖同构的「单一大视频 CDN」故事；和 Threads / Instagram 相比，它也不是同一套 Graph API 与 Reels 管线。要诊断，应优先在 Clash 连接日志里区分：HTTPS 的 REST/分页请求、wss 的实时通道、媒体 GET 的大对象——再决定是换节点、拆策略组，还是先修 DNS 解析链。
- 首屏与导航：通常混合
text/html、脚本文本与内联数据；对首包时延敏感。 - 信息流与互动：高频小 JSON、分页游标、点赞与回复；对同一会话内的一致性与小 TLS 握手的稳定性敏感。
- 媒体与富媒体：大带宽、可分段；若出口限速或与 HTML 同池排队，会拖慢总体验。
- 长连接：实时性依赖 WebSocket 或等价的长轮询/推送面；若规则把长连打到了不合适的 UDP/TCP 处理策略或老节点，会表现为「有缓存的旧帖、没新帖」。
AT 协议与「bsky 系」该拆成哪几类流量
你不必背熟 AT 规范全文，但要在心里有一张粗分类表。官方与社区客户端会访问 AppView / BGS 方向的公开接口主机、用于身份与发现的目录服务、以及放缩略图与短片的媒体子域。随着产品迭代，具体主机名会增删，因此比死记列表更重要的，是留抓日志的习惯：在 Clash 里打开带域名字段与策略命中的日志，跑一轮「开首页 → 刷时间线 → 点进 profile → 播放一段视频」。
把流量拆到主站与文档、公开 API 与 BGS 相关子域、媒体与 CDN 段、身份/发现（如 DID、 plc 等）四类，并给 WebSocket/长连单独一个策略组或「与 API 同组但延迟容忍不同」的子节点池，往往比把 bsky.app 一行粗匹配到底更稳。若你使用自建 PDS 或第三方实例，主机名还会进一步变化——这时应以你日志里真实出现的 DOMAIN-SUFFIX 为准，而不是只抄公开规则集。
与 Threads、TikTok 的错开点
Threads / Instagram 文侧重 Meta 系鉴权、Graph 与长视频/Story CDN；TikTok 国际版文侧重大陆 App 的鉴权、推荐与直播推拉流。Bluesky 更偏 开放图谱 + 可移植身份 与 AT 记录模型，规则集应单独维护，避免和 Meta/字节系域名行错绑到同一组导致过度代理或误直连。
在 Clash 里怎么设计：策略组、规则顺序与长连
推荐至少三个逻辑策略组（名字自定）：（1）社交/HTTPS 小请求，用于主站、API 与可分页的 JSON，挑低 RTT、握手稳定的线路；（2）媒体与大对象，可接受略高时延、但追求吞吐与连接复用；（3）与实时相关的长连，尽量与（1）共享同一地区逻辑，但避免把长连配到会频繁断线重连的跳变节点。若你只有一条「全局 PROXY」池，也至少用规则顺序把 DOMAIN-SUFFIX 与 DOMAIN-KEYWORD 细行放在宽泛 GEOIP 或 MATCH 之前，以免漏匹配。
对 WebSocket（wss://）而言，要确认你的内核/客户端没有误把长连当短连接去轮换节点；健康检查过密、url-test 的过短周期，都可能让长连在弱网下更难维持。可对照 《Character.AI 与长连接分流》 中关于长连接与 WebSocket 友好度的叙述，把思路迁移到 bsky 的实时面——差异主要在域与主机分布，不在「WSS 不是 HTTP」这个事实上。
若你使用 Clash Meta / Mihomo 的 rule-providers，可单独挂一份只含 bsky/AT 相关行 的轻量表，用较高的 interval 拉取、并在 mixin 中高优先级插入本机确认过的行；合并时注意不要和全局广告拦截列表同一条 REJECT 把 OAuth 与 telemetry 误杀，否则会出现「偶发能登、一刷新就全挂」的假象。
YAML 与规则行（示意，务必按日志核实）
以下仅为工程示意，真实主机名、后缀与 BSKY-HTTP 等组名需在你设备上自验；协议更新后请以连接日志与开发者工具 Network 列表为准增量维护。
# Illustrative only — replace policy groups; verify SNI/Host in logs
rules:
- DOMAIN-SUFFIX,bsky.app,BSKY-HTTP
- DOMAIN-SUFFIX,bsky.network,BSKY-HTTP
- DOMAIN-SUFFIX,bsky.social,BSKY-HTTP
- DOMAIN-SUFFIX,atproto.com,BSKY-HTTP
- DOMAIN-SUFFIX,atproto.dev,BSKY-HTTP
- DOMAIN-KEYWORD,bsky,BSKY-HTTP
- MATCH,PROXY
说明：DOMAIN-KEYWORD,bsky 会匹配主机名里含 bsky 的边侧请求，有过宽风险，适合短期验证、长期仍建议收拢为 DOMAIN-SUFFIX 或你在日志中能证实的主机列表。若你的规则集提供 GEOSITE 类标签，可在核实标签名后加一行。不要把未知长尾域名一揽子 REJECT，否则时间线会「缺块」而不报错；媒体域请在 Network 中确认后再单独设 BSKY-MEDIA 等组。
| 分层 | Clash 侧关注点 | 常见现象若未对齐 |
|---|---|---|
| API/JSON | 小 TLS、短 HTTP/2 请求；同 IP 多路复用 | 能进壳，列表空或无限 loading |
| 媒体与 CDN | 大对象、可分段、缓存命中 | 文能读、图频永远转圈 |
| 实时 / WSS | 长连保持、少换节点、少打断 | 只刷得出旧内容，新帖不推送 |
DNS、fake-ip 与多宿主机
当一个页面背后对十几个主机名发请求时，DNS 才是第一张多米诺。若 fake-ip 与规则侧期望不一致，你看到的会是「时好时坏」——同一节点下，某次解析走了缓存而另一次没走到。请完成 《DNS 泄漏与 fake-ip 排查》 中的基线，再为 bsky 开专项规则；必要时对媒体域与 API 域用同一 DNS 出口，避免分裂解析导致 Cookie 与区域路由错位。
合规与平台条款
本文只讨论在你有权操作的网络与设备上的连通性工程。请遵守当地法律、服务条款与所在机构政策；勿将技术配置用于未授权访问或扰动服务。
Web、官方客户端与「第三方 bsky 客户端」
浏览器与 Electron 系客户端通常都走系统代理或你启用的 TUN 捕获，排查路径类似；移动原生 App若不走系统代理，需要 Android 的 分应用代理 或 TUN 模式统一收流量。不同客户端请求的主机集合不保证一致，换客户端等于新做一次日志基线。
到 2026 年，「去中心化 + 可迁移身份」仍是 Bluesky/AT 被反复提起的原因，也意味着多实例与多 PDS 提供商会给规则增加变数：与其维护几千行死域名，不如以日志为驱动、每月花几分钟合并你机器上新出现的前缀进 rule-provider，可长期比「大杂烩」规则集更稳。
常见问题
我明明已经让 bsky.app 走代理了，为什么还超时？
因为只匹配壳域名时，API 与媒体常落在别的主机。请按时间顺序在日志中抓未命中你预期策略的主机，再补行，而不是只改节点地区。
能刷旧帖、收不到新帖，是 WSS 吗？
很像。把与实时相关的连接在日志里滤出来，看是否频繁 RST 或换出口；临时固定到一个稳定组做对比测试。
和 GEOIP 一起用时要注意什么？
先跑更具体的域名行，让 bsky/AT 相关不落入笼统的境外默认组，除非你明确希望这么走。可复习 《GeoIP MMDB 与 Country 规则》 中的规则顺序。
实操检查清单
- 在 Clash 中固定可读的日志，完成一遍「开页 → 刷流 → 媒体 → 发言」全路径。
- 为 AT / bsky 相关主机建立独立策略组与 rule-provider 片段。
- 将细域名行放在宽 GEOIP / MATCH 之前。
- 检查 DNS 与 fake-ip 是否与上述策略同向。
- 分别验证 HTTPS 小请求 与 wss 长连 是否落在预期出口。
- 大版本升级应用或换客户端后，重复跑一遍 1 与 2，防止主机集合漂移。
从可配置、可回滚的规则开始
把 Bluesky/AT 当作一类独立社交栈来养规则，你得到的不仅是「能刷」，还有可解释的排障：下一次超时，你先看是 API、媒体还是长连——而不是盲目换国家。