1 Why NotebookLM is not “just another google.com tab”
Through 2026, NotebookLM remains one of the most approachable Google AI surfaces for students and analysts who want citations back to their own PDFs and docs instead of a generic chat transcript. The product marketing emphasizes notebooks and sources, but the network reality is familiar: OAuth handshakes, streaming inference calls, telemetry, and blob storage for uploads all fan out across different suffixes. If your Clash split routing only toggles a blunt DOMAIN-SUFFIX,google.com rule—or worse, mixes contradictory “Google goes DIRECT” shortcuts with “AI goes PROXY” lists—you can easily land in a fragile state where the shell loads while background jobs fail.
Mihomo (the Clash Meta core) resolves each connection with ordered rules. The first match wins. That is excellent for precision, but it punishes ambiguous templates that treat Google as one bucket. NotebookLM benefits from the same discipline you would apply to Gemini and Google AI Studio: capture identity and API planes predictably, align DNS with the core, and verify with logs instead of guessing from the UI spinner alone.
Nothing here is legal advice about regulated networks or employer policies. The following sections describe practical routing patterns so responsible users can debug transport issues; compliance with local law and terms of service remains your obligation.
2 Symptoms when rules, DNS, or exits disagree
Misrouted NotebookLM sessions rarely print a single error string that says “fix your YAML.” More often you observe patterns. Sign-in loops or endless account pickers frequently mean accounts.google.com or oauth2.googleapis.com reached a different egress than the tab that hosts notebooklm.google.com, so cookies and risk engines disagree. PDF uploads that stall at ninety percent often trace to resumable upload endpoints on *.googleapis.com or storage fronts that your browser hits with a different resolver than Clash’s internal DNS module, which produces partial connectivity or TLS name mismatches under FakeIP.
“Generate summary” or notebook answers that never start, while the static UI renders, usually indicate WebSocket or long-lived HTTP/2 streams to unstated hosts that never matched your PROXY group—traffic fell through to DIRECT and hit a blackhole, or it bounced between nodes mid-session. Intermittent 403 responses can be account state, but they also correlate with geo-skewed exits when Google expects a consistent region for Workspace or consumer accounts. Treat the connection log as ground truth: reproduce the failure, sort by process and domain, and compare the outbound you intended against the outbound you actually got.
3 The hostname surface you should plan for
Start with the product entry: notebooklm.google.com is the primary web application host users bookmark. Behind it, Google’s standard identity stack appears—accounts.google.com, ssl.gstatic.com, www.gstatic.com, and related sign-in helpers. API-shaped traffic typically includes hosts under googleapis.com, sometimes with service-specific subdomains that change faster than blog posts. Static assets and thumbnails lean on gstatic.com and googleusercontent.com; blocking or splitting them inconsistently yields half-styled pages that look like NotebookLM regressions.
Depending on feature flags and account type, you may also see calls that overlap with broader Google AI infrastructure—similar to what we documented for Gemini in the AI Studio guide. Rather than freezing a mythical complete list, adopt a workflow: capture what your browser actually requests during sign-in, upload, and generation, then promote repeated suffixes into your own small override file. That file should sit high in your policy stack or merge early inside rule providers so it cannot be shadowed by stale community lists.
If you use Google Workspace, add the same caution we give enterprise Gemini users: split tunneling across countries can trigger step-up challenges unrelated to proxy throughput. Keep OAuth flows on a stable outbound when diagnosing NotebookLM issues.
4 Coexisting with generic Google DIRECT or PROXY rules
Many public rule sets include lines such as “send all google.com to DIRECT” for latency in specific regions, paired with separate “foreign AI” lists that proxy only a handful of domains. NotebookLM straddles both worlds: it is Google infrastructure, yet the inference and storage paths may require the same exit you use for other AI tools. The failure mode is predictable: your catch-all Google DIRECT rule matches first, NotebookLM API calls never reach the node that can reach Google cleanly, and the UI degrades in subtle ways.
Fix it with ordering, not hope. Place explicit DOMAIN and DOMAIN-SUFFIX rows for NotebookLM entry points, identity hosts, and the googleapis.com family above broad GEOIP or “domestic direct” shortcuts that touch Google. If you must keep a DIRECT path for some Google properties, narrow it with more specific suffixes instead of a giant DOMAIN-SUFFIX,google.com,DIRECT that swallows everything, unless you truly intend all Google products to bypass the proxy on that machine.
5 Illustrative DOMAIN-SUFFIX fragment
The YAML below is educational. Replace GOOGLE_AI with your real proxy group name, merge with subscription conventions, and trim duplicates. It intentionally overlaps with a solid baseline for Google services access because NotebookLM shares that graph; tighten or split groups if your threat model requires separating “AI” from “mail.”
# NotebookLM entry + obvious Google notebook context
- DOMAIN-SUFFIX,notebooklm.google.com,GOOGLE_AI
- DOMAIN-KEYWORD,notebooklm,GOOGLE_AI
# Identity and common web shell
- DOMAIN-SUFFIX,accounts.google.com,GOOGLE_AI
- DOMAIN-SUFFIX,oauth2.googleapis.com,GOOGLE_AI
# APIs and object storage (broad but common for uploads + backend)
- DOMAIN-SUFFIX,googleapis.com,GOOGLE_AI
# CDNs and user content delivery
- DOMAIN-SUFFIX,gstatic.com,GOOGLE_AI
- DOMAIN-SUFFIX,googleusercontent.com,GOOGLE_AI
- DOMAIN-SUFFIX,ggpht.com,GOOGLE_AI
# Optional: align with your Gemini / AI Studio profile
- DOMAIN-SUFFIX,google.dev,GOOGLE_AI
- DOMAIN-SUFFIX,ai.google.dev,GOOGLE_AI
DOMAIN-KEYWORD,notebooklm is convenient but can theoretically collide with unrelated telemetry strings; prefer suffix rules once you have log evidence. Always end your policy with a clear MATCH or default outbound consistent with the rest of your profile.
6 Rule providers: merge order and maintenance
Hand-edited lists teach the graph; rule providers scale the chore. When you import remote YAML, understand whether the provider prepends or appends, how often it refreshes, and whether it ships ad-blocking semantics that drop Google measurement or config hosts NotebookLM still expects. A provider that blackholes googletagmanager.com might be fine for privacy-focused browsing yet break OAuth-adjacent flows in edge cases—symptoms look like random AI product instability rather than a clean block page.
A pragmatic split for 2026 is to maintain a private “AI + NotebookLM overrides” provider or local rule file under version control, then stack broader Google lists beneath it. When Google introduces a new subdomain for streaming responses or regional failover, you add one line, roll forward, and your household or team inherits the fix without relearning the entire template. Document the merge order in a short README so future you knows why rule-providers entries appear in that sequence.
7 Keep account flows on one egress story
NotebookLM sign-in is ordinary Google OAuth from a transport perspective. What breaks sessions is inconsistency: the browser resolves accounts.google.com through the ISP resolver while Clash maps notebooklm.google.com through FakeIP, or the account flow hops countries because your selector auto-rotates nodes between page loads. For debugging, temporarily pin a single stable outbound in your GOOGLE_AI group, disable automatic failover, and retry. Once working, reintroduce automation carefully.
Corporate HTTPS inspection is another confounder. If a laptop trusts an enterprise root but Clash does not participate in that trust story, you can see TLS failures that resemble proxy misconfiguration. Do not enable casual MITM inside Clash to “fix” certificates; resolve trust at the proper layer. If you need inspection, use an explicit corporate forward proxy with distributed roots—not an ad hoc hack on a personal profile.
8 PDF uploads, quotas, and large-object paths
Upload pipelines often use resumable protocols across multiple chunks. If the first chunk routes through PROXY and a retry targets a different host class that matches DIRECT, the session dies mysteriously. Keep the entire upload dependency set on the same policy branch during diagnosis. Watch for rate limits: switching exits rapidly can look like abuse even when you are just debugging split rules.
Satellite extensions and privacy tools sometimes block “tracking” domains that Google reuses for configuration fetchers. If uploads work in a clean browser profile but fail in a hardened one, compare extension blocklists against your Clash reject rules. Two independent blockers create the worst failures because neither log shows the full story.
9 DNS, FakeIP, and Mihomo alignment
NotebookLM inherits the DNS sensitivity we see across Google AI properties. If Mihomo serves FakeIP while Chrome still queries the system resolver for the same name, you can get certificate mismatches or silent failures that show up only on streaming operations. Prefer one coherent strategy: let the core own DNS with explicit fallback, or disable conflicting OS stubs after you understand the trade-offs. For deeper patterns—DoH, DoT, and leak tests—see the Meta core DNS leak prevention article.
IPv6 is a recurring footgun. If the OS prefers IPv6 first but your rules assume IPv4-only exits, packets can bypass the path you think you configured. Test with aligned IPv6 routing or temporarily isolate IPv6 while you verify NotebookLM, then restore deliberately rather than leaving mystery toggles in place.
10 When TUN beats per-app proxy toggles
System proxy mode helps browsers, yet many helper processes ignore HTTP_PROXY environment variables. TUN pushes routing into the kernel so traffic is captured before user-space libraries decide how to connect. For a workstation that alternates between NotebookLM tabs, local scripts calling Google APIs, and background sync clients, TUN often yields fewer one-off fixes. Installation caveats, route loops, and verification steps are covered in the Clash Verge Rev TUN mode guide—the same lessons apply beyond any single Google SKU.
After enabling TUN, retest NotebookLM with the OS system proxy disabled to confirm the browser still traverses the virtual interface. Document the working combination so OS upgrades do not send you back to first principles in six months.
11 Troubleshooting checklist
- UI loads, generation never starts: Inspect streaming hosts in logs; move missing suffixes above broad DIRECT rules; pin a stable outbound while testing.
- Sign-in loops: Align DNS between OS and Mihomo; ensure identity hosts share the same proxy group as
notebooklm.google.com. - Uploads stall: Verify all chunk targets stay on one policy branch; check dual-stack IPv6 leaks; disable aggressive browser blockers temporarily.
- 403 or “not available” sporadically: Compare account region expectations with exit geography; rotate to a stable node before blaming NotebookLM itself.
- SDK or CLI tools fail while the browser works: Export consistent
HTTPS_PROXY/ALL_PROXYvariables, or rely on TUN for uniform capture.
12 Wrap-up
NotebookLM in 2026 is a strong example of a product-specific hostname sitting on a shared Google platform. Clash split routing shines when you treat it as a graph: ordered DOMAIN-SUFFIX rows, curated rule providers, DNS aligned with Mihomo, and optional TUN mode when applications ignore proxies. Compared with monolithic VPN clients, a well-structured profile lets you keep domestic latency-sensitive sites on DIRECT while still giving NotebookLM, Gemini, and APIs a consistent exit when your network requires it.
Invest a few minutes logging real traffic during sign-in, upload, and generation, then snapshot the working YAML. That discipline pays off the first time Google shifts a backend host and your teammates inherit a fix as a one-line provider update instead of a frantic group chat. When you want a desktop client that pairs readable connection logs with system proxy and TUN, start from the download hub on this site rather than chasing one-off installers—consistent clients make stable NotebookLM sessions easier to reason about.
Once routing becomes boring again, you can focus on sources and questions instead of connectivity—and that is exactly what a solid proxy stack should deliver for NotebookLM users this year.
