為什麼 Perplexity、NotebookLM 比傳統網頁更「挑線路」？
若你只用瀏覽器看靜態新聞，瓶頸多半在單一主機名稱與圖片 CDN；但AI 搜尋與研究型工具的體感速度，往往被「同一畫面背後的十幾條連線」決定。Perplexity這類服務會同時請求主站、搜尋與推論相關端點，有時還會落到不同後綴或第三方基礎設施上。Google NotebookLM則深度綁在 Google 帳號、雲端儲存與即時同步流程裡，除了產品入口網域，還常牽涉登入、權杖交換、靜態資源與分析類子網域。
當 Clash／Mihomo 使用過於粗糙的預設策略時，常見症狀不是「整站打不開」，而是頁面骨架出現了，但對話框一直轉圈、上傳 PDF 卡住、或每隔一陣子就要重新登入。這通常代表：某幾條關鍵連線被直連到不穩定的路徑，或被寬鬆的 GEOIP／訂閱規則提前命中到錯誤的策略組；也可能與 DNS 解析模式與規則匹配順序不一致有關。
若你對 rules 與代理群組仍不熟，建議先透過站內使用文件把基礎架構跑通，再回到本文專注在「研究型 AI」的流量特徵上補規則。
和 IDE／GitHub 分流哪裡不同？
本站另有一篇針對 Cursor、GitHub 與擴充市集的分流說明，重心在開發工具鏈與長時間下載、語言伺服器連線；本文則聚焦網頁型 AI 搜尋與筆記研究。兩者都會碰到多網域，但優先關注點不同：開發情境常要顧及行程名稱、套件 CDN 與特定 API；研究型工具則更常遇到OAuth 驗證跳轉、同一帳號體系下的跨子域請求，以及瀏覽器裡WebSocket／長輪詢類通道對延遲抖動更敏感。
因此建議不要把「所有 AI」塞進同一條過寬的規則裡；可為研究型 AI 搜尋單獨準備一組策略，必要時與程式開發流量分開調校節點。若你也使用 IDE 類工具，可交叉參考Cursor／GitHub 分流一文中的排序觀念，但請勿直接複製其網域清單當成 NotebookLM 的完整解方。
先建「研究型 AI」策略組，再寫規則
實務上建議先新增一個語意清楚的代理群組，例如 RESEARCH_AI，內含你測過對HTTPS 長連線較穩定的節點，或啟用延遲測試自動選線。接著在 rules 區段最前方（寬鬆規則之前）放入與 Perplexity、NotebookLM 相關的 DOMAIN／DOMAIN-SUFFIX 條目，全部指向 RESEARCH_AI。
這樣做的好處是：日常觀影、下載或大流量任務可以留在另一組策略，避免與「需要低抖動的搜尋／對話」搶同一個出口；日後若官方更換後端網域，你也只需要更新這一小段規則，而不必動到整份訂閱。
若你大量使用第三方規則集，可搭配Rule Providers 進階指南把長清單模組化，讓主設定檔保留一小段「研究型 AI」專用的高優先規則。
規則配置範例（務必以實際連線為準）
下列 YAML 僅為結構示意；真實上線網域會隨產品改版而變動，請一定以瀏覽器開發者工具的「網路」面板或 Clash 連線紀錄中失敗請求的主機名稱為準。將 RESEARCH_AI 替換成你設定檔中的實際策略組名稱。
# Example only — replace RESEARCH_AI with your real policy group name
rules:
# Perplexity-oriented (verify in your browser/network log)
- DOMAIN-SUFFIX,perplexity.ai,RESEARCH_AI
- DOMAIN-SUFFIX,pplx.ai,RESEARCH_AI
# Google / NotebookLM-oriented (account + static + APIs often split)
- DOMAIN-SUFFIX,google.com,RESEARCH_AI
- DOMAIN-SUFFIX,googleusercontent.com,RESEARCH_AI
- DOMAIN-SUFFIX,gstatic.com,RESEARCH_AI
- DOMAIN-SUFFIX,googleapis.com,RESEARCH_AI
- DOMAIN-SUFFIX,ggpht.com,RESEARCH_AI
- DOMAIN-SUFFIX,googlevideo.com,RESEARCH_AI為什麼連 gstatic.com、googleusercontent.com 都要寫？因為 NotebookLM 與多數 Google 網頁應用一樣，前端腳本與使用者內容常落在與主站不同的後綴上；只代理主域名而讓靜態或儲存類請求直連，最容易出現介面半載入、按鈕無反應。相對地，若你把整段 google.com 一刀切到代理，也可能影響你本意要直連的其他 Google 服務——此時可改寫較窄的 DOMAIN 規則，或依客戶端能力改用規則集細分，取捨在於你可維護性。
Perplexity部分亦可能新增 CDN 或合作方網域；若更新客戶端或瀏覽器外掛後突然變慢，請重新匯出連線清單，把新出現的主機名稱補到規則表最前段再測試。
CDN、驗證與長連線：最容易漏的環節
研究型工具除了「看得到的主站」，還有三類流量特別容易踩雷。第一是靜態資源與字型，延遲一高，首屏就顯得「很慢」。第二是登入與權杖：若 OAuth 相關請求走了與 API 不同的出口，可能出現偶發 403、無限重新導向或 Cookie 行為異常。第三是即時更新通道：節點若頻繁斷線，體感會像「問一句卡很久」，其實是長連線在抖動。
處理方式仍是老原則：規則由上而下匹配，先命中者優先；把已確認的網域放在會誤傷它們的寬鬆規則之前。若你懷疑是解析問題而非節點問題，請一併對照DNS 防洩漏與設定指南，確認 fake-ip、嗅探與規則的組合是否讓「同一主機在不同階段走了不同路」。
瀏覽器、TUN 與「沒進代理」的連線
多數使用者透過瀏覽器使用 Perplexity 與 NotebookLM，理論上應走系統代理；但若你使用獨立封裝的桌面程式、或瀏覽器設定成「永不使用系統代理」，則仍可能繞過 Clash。此時可考慮 TUN 模式讓流量強制進入堆疊，再靠規則分流；也要留意與其他 VPN、公司防火牆是否衝突。
若僅有特定網站慢、其餘正常，優先檢查是否為單一網域漏規則，不要一開始就更換整個訂閱；把可疑主機名稱暫時以 DOMAIN-SUFFIX 置頂測試，能快速驗證假設。
建議除錯順序
當 AI 搜尋再次卡頓，建議依序檢查：（1）該次操作涉及的主機名稱是否出現在 Clash 連線日誌；若沒有，代表流量未經代理或未被 TUN 攔截。（2）若有日誌，命中的是哪一條規則、走向哪個策略組。（3）將最關鍵的網域手動提到規則表前段後是否恢復正常。（4）若仍失敗，再更換節點或協定，並觀察是否僅特定協定不佳。
請保留務實心態：雲端產品的後端會變，教學只能提供方法與範本。定期依實際連線更新一小段規則，比一次寫死巨大清單更容易維護。若你希望整體反應更快，亦可延伸閱讀Clash 提速實用技巧，從 DNS 與訂閱測速收斂延遲來源。
寫在最後
相較於把全部流量丟進單一「自動選線」群組，為研究型 AI 搜尋保留一組穩定出口，通常能同時改善速度與可預期性：該直連的不被誤傷，該走代理的 API 與靜態資源也不會落在錯誤路由上。把這段 規則配置整理成可複製的片段後，換機或換訂閱時也能快速還原。
選擇連線紀錄清晰、規則編輯方便的用戶端，能讓你在遇到 Perplexity 或 NotebookLM 卡頓時少花一半猜測時間。若你尚未安裝或正考慮更換客戶端，可從本站下載頁取得對應平台版本，先以預設策略跑穩，再將本文的「研究型 AI」規則逐步併入。
若需查核開源授權、上游版本或社群討論，亦可另行前往 GitHub；日常安裝與更新用戶端仍建議以本站下載入口為主，與瀏覽原始碼的用途分開，較不易誤用非預期的組建連結。