2026 用 Clash 访问 NotebookLM：网页与音频域名分流实测

读完本文你能得到什么

你将能按轮次自测：（1）冷开 notebooklm.google 产品页时，日志里最先稳定出现的主机名集合；（2）完成 Google 账号会话、上传或同步来源文档时，是否额外命中 accounts.google.com、oauth2.googleapis.com 等鉴权链；（3）触发摘要、对话或音频概览时，是否出现高频 googleapis 子域、大体积静态资源域名、或带随机前缀的媒体主机。随后把这些主机名归入同一 proxy-groups 专组，检查更靠前的 GEOIP,CN、国内直连集或过于宽泛的 KEYWORD 是否抢答。全文不承诺永不变化的完整域表——Google 会改版前端与边缘；文中出现的 notebooklm.google、googleapis.com 等仅作常见模式示意，若与你当前客户端或 Workspace 策略不一致，以你环境里的连接日志为准替换。

和 Gemini、ChatGPT 等专文差在哪

本站已有 Google Gemini 专文（侧重 gemini.google.com、generativelanguage.googleapis.com 等）、ChatGPT 与 OpenAI 文等，它们共享「产品前端、鉴权、API、静态 CDN可能分属不同后缀」的写法。

NotebookLM 的增量在于：（1）主产品入口明确落在 notebooklm.google，与 gemini.google.com 的产品树并行；（2）多源文档与笔记本状态同步，往往拉长 googleapis 侧会话与上传类主机名列表；（3）音频概览与播报类体验，常见二次拉取媒体或大对象，主机名可能更像「Google 通用媒体栈」而非「带 notebooklm 字样」；（4）Workspace／个人账户与管理员策略差异，会让你在日志里看到不同的受限路径提示——网络层仍能先对齐连接，再区分账号策略。因此「只照搬 Gemini 文里那一小段 DOMAIN」在多数环境下不够；而「把整个 *.google.com 无差别代理」又可能和你在同一台机器上对其它 Google 子产品的精细策略冲突。下面步骤把可观测域名与可重复策略对齐。

常见表现：不只「网页打不开」一种

用户侧可能遇到：（1）产品壳能渲染，点「生成」或切换笔记本后长时间转圈，开发者工具里某一主机名 pending 或流式请求中断；（2）文本区正常，点击播放音频概览才失败——多见于媒体域名落在另一出口或被国内直连规则误伤；（3）登录 Google 账号时循环跳转，而其它 Google 服务看似正常——常见于鉴权子域与业务子域被拆到两个策略组；（4）仅静态脚本或图标裂了，核心交互还在——常是 gstatic／googleusercontent 未与主会话同组。请先把服务条款、账号地区与组织政策与本机路径问题分开；后者才是 Clash 规则能覆盖的那一半。若你还在并行排 IDE 与 GitHub 类链路，注意不要让「整段 Git 流量」与浏览器里 NotebookLM 会话共用一套频繁切换的测速组，导致会话 cookie 与出口观感异常。

另一类容易误判的是多标签页与扩展预加载：前台只有 notebooklm.google，后台却可能因同源策略或预连接触达其它 Google 主机名。RULE-SET 若在订阅里把某类 Google 用途标成直连，而你的笔记本会话又必须从代理出口对齐地区，就会出现半直连半代理的拼接状态。处理办法仍是以连接日志时间戳为准：在复现故障的十秒窗口内，只看与点击动作对齐的那几条会话，再决定是收紧某条 DOMAIN-SUFFIX、还是把误伤的大规则挪到更后面。

第一步：确认 Clash 真的接管了浏览器与相关进程

仅开「系统代理」时，部分子进程或沙箱内 WebView 会绕开。若点击生成后数秒内连接日志里完全没有你在《网络》面板看到的主机名，应优先查：是否需要 TUN、是否有多网卡、公司 VPN 与 Clash 争用默认路由。可复阅 TUN 模式深度解析。没有「进栈」的排查，调再多 DNS 也只是在动表象。

第二步：分段抓取与你环境匹配的主机名

建议分多轮、每轮十到四十秒：（1）冷开官方入口页，仅浏览不做登录；（2）完成 Google 账号会话绑定；（3）新建笔记本、上传或挂载来源、触发一次总结或对话；（4）若使用音频类输出，完整走一遍生成—播放，观察是否在播放按钮点击后出现一长串新媒体连接。在日志中通常会看到：notebooklm.google 及其子域；accounts.google.com、oauth2.googleapis.com 等鉴权相关主机；若干 *.googleapis.com 业务接口；*.gstatic.com、*.googleusercontent.com 等静态与大对象路径；以及少量分析或错误上报域（按你的隐私与策略决定是否单独直连）。对能复现故障的主机名，优先用 DOMAIN 精确写在前，再补较宽的 DOMAIN-SUFFIX，并保证顺序在会「抢答」的 GEOIP,CN 与过宽关键词之前能生效。策略组命名可对照 Clash 代理组（proxy-groups）完全指南，为 NotebookLM 单开一组，例如 NOTEBOOKLM_STACK。

音频 CDN 在字面上常呈现为长随机路径或与产品名无关的 googleusercontent／存储类子域，和「带 notebooklm 字样的前台」看起来毫无关系。浏览器与系统播放器若走不同栈，也请分别取样，避免出现「页面能点、系统级播放全超时」的假对比。若你希望把整条链约束在可读性更好的规则列表里，可维护一份仅限本机的增量列表：每条记录注明发现日期与会话上下文，避免半年后无人知道某条怪异主机名从何而来。媒体多时延的对照思路，也可交叉阅读 OpenAI Sora 与 DNS 分步实测 中「解析链与策略链分离」的段落。

分流规则示意：专组 + 与日志一致的前置 DOMAIN

下例只说明结构，占位符须替换为你本地日志与订阅中的真实组名、节点与主机名。若用 RULE-SET，请确认集合会随服务侧调整更新，并仍以你日志为准做增补。

# Example only — replace domains and group names from your logs / config
proxy-groups:
  - name: NOTEBOOKLM_STACK
    type: select
    proxies:
      - YOUR_NODE_A
      - YOUR_NODE_B

rules:
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - DOMAIN-SUFFIX,notebooklm.google,NOTEBOOKLM_STACK
  - DOMAIN,accounts.google.com,NOTEBOOKLM_STACK
  - DOMAIN-SUFFIX,googleapis.com,NOTEBOOKLM_STACK
  - DOMAIN-SUFFIX,gstatic.com,NOTEBOOKLM_STACK
  - DOMAIN-SUFFIX,googleusercontent.com,NOTEBOOKLM_STACK
  - DOMAIN,exact-media-host-from-your-logs.example,NOTEBOOKLM_STACK
  - GEOIP,CN,DIRECT
  - MATCH,DIRECT

更细的「让指定 App 走指定节点」顺序思想，可见 自定义规则教程：让指定 App 走指定节点。宽后缀能省事，也可能带来过度代理；若你追求最小代理面，可在跑通后把 googleapis.com 收束为日志里真实出现的子域 DOMAIN 列表，并保留回滚预案。

DNS、fake-ip 与「规则写了不生效」

启用 fake-ip 时，域名与规则匹配依赖 Clash 的解析与缓存。若 IP-CIDR 带 no-resolve 却在顺序上压过域名类规则，或系统还有旧 IP 缓存，会表现为「配置已改、页面还是旧行为」。排错时一次只变一类量：先固定 nameserver 与 fallback，核对 fake-ip-filter 是否把业务域名排进过滤列表，再清浏览器站点数据或换无痕。

当 NotebookLM 页面与广义 Google 混用时，若你给 google.com 写过全局策略，又希望国内某些 Google 子用途保持直连，要特别小心子域覆盖与子域顺序：更具体的 DOMAIN 应写在概括性 DOMAIN-SUFFIX 之前。IPv6 若在接口上同时启用，也要确认 IP-CIDR6 并未让部分会话绕开 Clash，从而造成「同一网站有时通有时断」的观感。DoH 能抗篡改，也可能抬高首包时延；若你追求「对话首字更快」，可在日志里观察 DNS 阶段耗时，再决定是否拆分策略。

稳定访问的实测顺序建议

在确认进栈与专组后，用同一账号、同一浏览器配置文件在两条不同出口上各试一轮，对比首包时延、流式分块与间歇性 429。企业网络若对 TLS 做中间人检查，会出现证书层错误，这类问题不能靠多换两个机场节点碰运气解决。请在你有权使用的网络与账号条款下做测试，遵守当地法律与组织政策；本文只帮助你在自管环境里把 Clash 的分流规则、DNS 与可观测连接对齐。

推荐排错检查表

1. 是否进栈：打开产品页与完成一次生成或播放的三十秒内，连接日志有对应进程与主机名。
2. 少变量：暂关其它 VPN／虚拟网卡，避免多默认路由与 DNS 争用。
3. 分段抓域：未登录、已登录、文档同步、文本生成、音频播放分五轮抓，合并去重后写规则。
4. 专组统一：notebooklm.google、鉴权子域与你在日志中看到的 API／媒体 落在同一 NOTEBOOKLM_STACK，检查更前规则无抢答。
5. 对齐解析：fake-ip、no-resolve 与 DoH 不自相矛盾，必要时清站点数据并避免系统 hosts 与 Clash 双写冲突。
6. 再比节点：在专组内做短窗 A/B，不在全局无目的地切换订阅标签。

小结

用 Clash 稳定访问 Google NotebookLM，在工程上多数可以还原为：notebooklm.google 应用流量、Google 账户与 googleapis／静态／媒体栈在多段出口上不一致，或 分流规则、DNS、fake-ip 与 no-resolve 的时序不兼容。用连接日志做清单，用专组与顺序固化策略，用检查表把变量一次一个地消掉，比只搜索泛化「谷歌加速器」能更快落地。和站内 Gemini、ChatGPT 专文相比，NotebookLM 这条链更强调多模态与音频分发在日志里的「第二种长相」，但「分步、日志驱动、先接管再切规则」的套路仍是同一套。

若你希望用维护积极的核心与图形客户端、从本站 下载页 获取安装包，并配合 使用教程 与上文链接搭一套固定工作流，长期成本会更低。还没有合适的本机环境时，可以从这里先取得客户端与文档入口：→ 立即免费下载 Clash，开启流畅上网新体验。