为什么 AI 搜索「看起来就一个网站」,却更容易卡
和刷新闻、看视频不同,研究型 AI 搜索往往在极短时间内串起多条连接:打开页面只是第一步,随后会有接口轮询、流式输出、嵌入卡片、引用跳转,以及后台对模型与检索服务的调用。很多服务还会把静态资源、字体、脚本放在独立的 CDN 域名上,把登录与令牌刷新放在另一套身份域名上。
在 Clash 里,这意味着你不能只记住一个主页域名。只要其中任意一条连接被错误地丢进「慢节点自动选路」、被 GEOIP 误判、或走了与 DNS 解析不一致的出口,用户看到的现象常常是首屏出来了但回答卡住、登录反复跳转、上传源后预览一直转圈。排障时最有价值的问题不是「网好不好」,而是这一条 SNI 命中了哪条规则、最终落在哪个策略组。
和「编程 IDE + GitHub」分流有什么不一样
如果你已经读过《Cursor 和 GitHub 总超时?用 Clash 规则给 AI 编程工具单独分流》,可以把那条线理解成编辑器更新、扩展市场、Git 与 REST API的工程链路。本文聚焦另一类日常需求:浏览器里的 AI 搜索与笔记本式研究工具,其域名集合更偏向网页应用、检索与 Google 账号体系,而不是 VS Code 市场或 githubusercontent.com 大文件拉取。
两者可以共用同一个「海外高质量节点」策略组,但规则集最好拆开维护。原因很简单:IDE 场景你会频繁改扩展与工具链域名;AI 搜索场景你更关心鉴权链与接口域名是否被广告列表或宽泛直连表误伤。拆开后,回滚与对照实验都更轻松。
Perplexity:网页、接口与静态资源的多域名链
以常见架构为例,Perplexity 类服务往往会同时出现主站与 API 子域、以及承载脚本与图片的第三方或自有 CDN。具体 hostname 会随产品迭代与灰度变化,因此不建议照抄一份「永久域名表」就放手不管;更稳妥的做法是:在出问题当天打开客户端连接日志,把实际出现的 SNI 按频次排序,优先给高频域名写规则。
实战上可以先覆盖主业务后缀(例如 perplexity.ai 一类),再观察是否仍有独立 API host 或统计域名落在默认策略里。若你把整个浏览器都绑在「自动选路」上,Perplexity 的长连接可能和视频网站、下载流量抢同一个 URL-Test 结果,表现为偶发秒开、偶发十几秒无响应。为 AI 搜索单独挂一个策略组,本质是把这些长连接从「全局抢节点」里摘出来。
NotebookLM:入口、文档与 Google 鉴权往往不是同一后缀
NotebookLM 运行在 Google 生态内,用户最容易忽略的一点是:笔记本页面本身与Google 账号登录、OAuth 回调、API 与存储往往分布在多条域名上。社区排障里较常见的类别包括:承载产品与控制台页面的 host、通用 API 与 RPC 相关的 googleapis.com、静态资源常用的 gstatic.com、以及登录流程里的 accounts.google.com 等。
这类产品的典型故障模式是链路分叉:页面框架能加载,但一进入「选文件 / 同步来源」就卡住;或登录窗口循环重定向。Clash 视角下,这经常是一部分请求走了直连、另一部分走了不稳定代理,导致 Cookie 与令牌在不同出口之间不一致。处理思路不是盲目全局代理,而是把鉴权相关域名与笔记本业务域名绑定到同一策略组,并保证这组节点在你当前网络下对 Google 路径足够稳定。
先做策略组:给 AI 搜索预留独立出口
在 proxy-groups 里新增一个语义清晰的组名,例如 AI_SEARCH,内部可以是手动选节点、也可以是延迟测试组。关键是:你在规则里引用的是组名,而不是某个具体节点,这样日后换机场或换优选策略,不必批量改规则。
若你同时需要「日常浏览省流量」与「AI 搜索要稳定」,可以让 AI_SEARCH 使用与 PROXY 不同的节点池,或在手动组里固定一条低丢包线路做对照。对照实验的价值在于:当问题消失时,你能确定瓶颈在策略组选路而不是某个单域名配置写错。
规则顺序:鉴权、API、CDN 谁先匹配
Clash 系列内核按规则自上而下、命中即停。对 NotebookLM 这类产品,建议把登录与账号相关域名写在靠前位置,再写业务 API 与主站后缀,然后是静态资源域名。否则可能出现:宽泛的直连列表抢先匹配了某个 googleapis.com 子域,导致它与主站走了不同出口。
若你使用 RULE-SET 托管大列表,记得把「AI 搜索 / Google 研究工具」专用列表插在过于激进的广告拦截或未知域名 REJECT 列表之前,避免误杀接口域名。更系统的 provider 写法见《Clash Rule Providers 进阶指南》。
配置示例(务必按本机日志增删域名)
下面是一段示意性片段:策略名 AI_SEARCH、DIRECT 等需替换为你配置文件中真实存在的名称;域名仅为常见形态示例,上线前请用连接日志核对。
# Example: AI search / research tools (adjust policy names and domains to your logs)
proxy-groups:
- name: AI_SEARCH
type: select
proxies:
- PROXY
- AUTO
- DIRECT
rules:
# Google auth chain (NotebookLM often depends on consistent egress)
- DOMAIN-SUFFIX,accounts.google.com,AI_SEARCH
- DOMAIN-SUFFIX,ogs.google.com,AI_SEARCH
# Google APIs / static (broad; trim if you need split routing)
- DOMAIN-SUFFIX,googleapis.com,AI_SEARCH
- DOMAIN-SUFFIX,gstatic.com,AI_SEARCH
# Notebook entrypoints (verify current host in logs)
- DOMAIN-SUFFIX,notebooklm.google.com,AI_SEARCH
# Perplexity product domain(s)
- DOMAIN-SUFFIX,perplexity.ai,AI_SEARCH
- MATCH,PROXY
若你希望更「细粒度」地把某些 Google 域名直连、某些走代理,务必用更具体的 DOMAIN 规则靠前覆盖泛后缀规则,并在改动后观察是否出现新的循环登录。对大多数用户,「鉴权与业务同学一组」比「极致拆 CDN」更省心。
与 DNS、fake-ip 对齐
规则写得正确,但系统或浏览器把 DNS 查询旁路到运营商,仍会出现命中了 PROXY,却连向意外 IP的假象。使用 fake-ip 时,要确保分流与解析路径一致;对特定后缀使用 nameserver-policy 时,也要避免把 Google 相关查询指到缓慢上游。完整自检流程可参考《Clash DNS 防泄漏配置完整指南》。
若你在调整规则后仍感觉「第一次慢、后面快」,可以结合《Clash 提速实用技巧》里关于订阅更新、缓存与重试的章节,检查是否把过多域名放进了高频 URL-Test 组,导致冷启动时被动态换节点打断。
排错:从「半屏能用」判断链路分叉
建议按固定顺序收集信息:第一,在日志里记录失败请求的目标域名、端口、命中策略;第二,核对 DNS 解析是否与内核一致;第三,临时把 AI_SEARCH 固定到单一已知可用节点做二分法;第四,检查浏览器扩展、公司代理或安全软件是否对 accounts.google.com 走了系统直连旁路。
若只有上传来源或生成摘要失败,而页面导航正常,优先怀疑某个 API host 仍落在 MATCH 兜底或其他策略组。此时不要急着重写整份配置,而是在规则顶部追加一条更具体的 DOMAIN 规则,确认命中后再考虑是否合并进自己的 rule-provider。
客户端与内核版本
部分规则类型、TUN 与 DNS 行为与内核版本强相关。若示例字段在你的配置中报错,请先对照《Clash Meta(Mihomo)升级完整指南》确认语法与能力是否匹配,再排查业务域名本身。
开源与下载入口
Mihomo 等内核在 GitHub 上公开维护;若需查阅实现细节或提交问题,可访问 Mihomo 仓库。安装图形客户端与集成发行版时,建议优先使用本站下载页提供的入口,与源码仓库用途区分开。
合规与边界
本文仅讨论在合法合规前提下,使用开源代理客户端优化本地网络体验的技术思路,不构成对任何地区法律法规或服务条款的规避建议。请尊重平台政策与数据使用边界,在授权范围内配置网络与代理。
小结
Perplexity、NotebookLM 代表的AI 搜索与研究型工具,本质是「多域名 + 鉴权链 + 长连接」叠加场景。把它们从通用浏览器流量里拆出来,用独立策略组承接,并认真排列规则优先级,往往比反复切换全局模式更有效。
与 IDE / GitHub 分流相比,你维护的重点会从「扩展市场与 raw 下载」转向「登录一致性与 API host 覆盖」。把专用规则集版本化、随日志迭代,再配合稳定的 Mihomo 系客户端,就能把偶发卡顿收敛成可复现、可修复的几条记录。若你正准备搭一套长期使用的环境,可先前往本站下载页获取对应系统版本,用最小规则验证 AI 搜索链路是否恢复,再逐步合并进主配置。→ 立即免费下载 Clash,开启流畅上网新体验