為什麼 Perplexity 特別容易出現「半套可用」的分流症狀？

AI 搜尋類產品把索引、對話推理與外連引用拆在多段請求裡：外觀上你只看到單一網址列顯示 perplexity.ai，實際上瀏覽器或 App 可能同時向多個子網域、第三方 CDN、圖床或分析端點發請求。若 Clash 規則只涵蓋首頁主機名，或 Rule Providers 合併順序讓某些請求先落到了 DIRECT／錯誤的策略組，就會出現殼載入完成，核心問答卻逾時或被阻斷的割裂感。

與本站既有的 OpenAI、Google Gemini、xAI Grok 等文不同，Perplexity 使用的網域集合不應混在一起維護；否則搜尋意圖重疊、讀者亦難以在書籤中快速切換「我要修哪一條產品線」。把 Perplexity 收斂成獨立策略組，你也能在排障時先確認規則命中，再把換節點留到真正懷疑出口品質的階段。

以下內容以 Clash／Clash Meta（mihomo）常見寫法為例；核心概念是「由上而下、先命中先生效」。實際欄位名稱請以所使用版本文件為準，但分流規則與策略組的搭配邏輯在各分支之間高度相通。

實務上會遇到哪些主機名？（以 perplexity.ai 為樹根整理）

服務會改版，子域也會增減；下表整理多數情境下最常需要覆蓋的後綴與用途，並請你以連線日誌裡的真實主機名為最終依歸。若遇到清單未列出的新子域，請優先補 DOMAIN 精準匹配，再視情況提升為 DOMAIN-SUFFIX。

  • 主站與網頁應用：perplexity.ai、www.perplexity.ai——對應一般瀏覽器使用與登入流程。多數入口與前端路由會落在這棵樹下。
  • 短鏈與品牌週邊：pplx.ai——常見於分享連結、跳轉或對外行銷網域；若只為 perplexity.ai 寫規則而忽略此後綴，可能出現「點分享連結可開、回到主站卻異常」的錯覺。
  • 實驗／延伸功能（若你的帳號已啟用）：例如以 labs. 或應用子域開頭的 API 主機名——這類名稱更動較快，建議以日誌增量補規則，而非一次寫死超長枚舉。
  • 靜態資源、縮圖與嵌入內容：部分縮圖、圖示或引用預覽可能經由第三方 CDN 或獨立子域提供。當圖片能載入、文字回答卻失敗時，請比對瀏覽器「網路」分頁中的失敗請求主機名，通常會看到與首屏不同的網域，需要在 Clash 內一併納入同一策略組或另外拆組。
不要只信網址列 使用者肉眼看到 perplexity.ai，不代表所有 XHR／WebSocket 都只打向同一主機名。把「問答逾時」當成 API 路徑問題來看，會比先懷疑帳號權限更符合現象。

可複製的分流骨架：DOMAIN-SUFFIX、插入位置與策略組名稱

在 Clash 中，DOMAIN-SUFFIX 會比對網域後綴樹；DOMAIN 則對應完整主機名。規則由上而下命中，先匹配的條目優先，因此請將希望走「Perplexity 專用出口」的條目放在過寬的 GEOIP／MATCH 或其它 Rule Providers 可能攔截的位置之前。

下方為示意（策略組名稱請替換成你設定檔內實際存在的名稱）：

rules:
  - DOMAIN-SUFFIX,perplexity.ai,Perplexity-AI
  - DOMAIN-SUFFIX,pplx.ai,Perplexity-AI
  # Optional: add explicit API/app subdomains if logs show misses
  - DOMAIN,api.perplexity.ai,Perplexity-AI
  # ... merge point with Rule Providers — order matters ...
  - GEOIP,CN,DIRECT
  - MATCH,手動選擇

若你使用遠端規則集，請特別檢查合併順序：許多大型清單會內建「頂級域或常見 CDN 的廣義規則」，可能在你自訂的 Perplexity 條目之前就決定了走向，導致你以為「已經寫了 DOMAIN-SUFFIX,perplexity.ai」，日誌卻顯示命中別條。YAML 與 Rule Providers 指南對插入點有更完整的說明，建議先讀合併邏輯再回來微調。

與 Grok、Gemini、DeepSeek 專篇的關係 上述後綴僅針對 Perplexity 品牌相關網域；若你同時使用多家 AI 搜尋或模型 API，建議分模組維護，避免單一 MATCH 兜底把所有流量攪在一起，日後除錯會非常痛苦。

策略組順序怎麼設，比較不怕「規則對但節點爛」？

策略組在設定檔裡通常以 proxy-groups 區塊宣告，並在 rules 中以名稱引用。為 Perplexity 單獨建一組（例如上例的 Perplexity-AI）的好處是：你可以手動挑一條對長連線／TLS 友善的節點，或設計 url-test 在幾條後備線路之間輪替，而不必動到整份訂閱的預設「手動選擇」。

實務上請注意三點。第一，策略組名稱穩定、可讀，避免和訂閱自動產生的別名衝突。第二，上層規則只引用策略組名，而非寫死單一節點，未來換機場時不必全檔改名。第三，若你尚未升級至支援較新語法與行為的 Meta 核心，請先完成核心升級，再調整進階測速或子策略。

proxy-groups:
  - name: "Perplexity-AI"
    type: select
    proxies:
      - "自動測速"
      - "手動備援"
  - name: "自動測速"
    type: url-test
    proxies:
      - "節點A"
      - "節點B"
    url: "https://www.gstatic.com/generate_204"
    interval: 300

要強調的是：規則正確只保證流量進了預期策略組；若該組內唯一可用的節點品質不佳，仍會在應用程式層看到逾時。排查順序應為「先確認命中規則與策略組正確，再在同一組內更換節點」，與「一開始就懷疑 DNS 或核心未開」分開判斷，會省掉大量時間。

常見失敗對照表：症狀 → 優先懷疑點 → 建議動作

下表用於在「情緒性重啟客戶端」之前，提供一條理性的檢查順序。若與下表不符，仍以日誌中的主機名與命中規則為準。

你看到的現象 較可能的原因 建議先做
首屏 UI 出現，送出問題後長時間轉圈或顯示網路錯誤 實際 API 主機名未覆蓋、或被更上層 Rule Provider 先匹配；少數為節點對長連線不佳 對照日誌主機名，補 DOMAIN／DOMAIN-SUFFIX 並上移順序；再於同一策略組換節點
縮圖／圖示／引用卡片空白，但其它網站圖片正常 圖床或追蹤子域走了直連／不同策略組；或瀏覽器混合內容被擋 在開發者工具列出失敗請求網域，逐一納入或合併到同一策略組
手機 App 可用，桌機瀏覽器不行（或相反） 一端走系統代理／一端直連；或 App 使用自有網路堆疊 分別擷取兩端主機名；必要時為 App 端開 TUN 或檢查是否略過代理
偶發成功、多半失敗，錯誤訊息與地區／登入無關 出口 IP 被目標站暫時限制；節點擁塞；HTTP/2 相容性 在已確認規則命中後，於同一策略組更換區域或線路類型
同一 Wi‑Fi 下，只有特定 DNS 環境異常 本機／路由器解析結果與 Clash DNS 設定不一致，導致 IP 規則跟著偏掉 檢查 Clash DNS、fake-ip 與 redir-host 取捨，延伸閱讀DNS 模式教學

DNS、TLS 與「阻斷」三個字：何時不是 Clash 的錯？

許多讀者習慣把所有「連不上」都歸因於阻斷。實務上，若 TLS 交握在第一包就失敗，或解析得到明顯不屬於該站的位址，問題可能出在DNS 污染、本機安全軟體、企業網路 SSL 檢查，而非單純代理規則。此時即便你把 perplexity.ai 寫得再漂亮，也無法挽救錯誤解析或中間人裝置造成的斷線。

建議的理性順序是：先在 Clash 日誌確認目標主機名與策略組是否如預期；再用同一台機器比對系統解析結果；最後才檢查節點與上層網路。這個順序與本站其他AI 搜尋／模型 API 教學一致，能幫你建立長期可複用的分流規則維護方法，而不是每次熱點產品更新就重新徒手試錯。

常見問答（精簡版）

只寫一條 DOMAIN-SUFFIX,perplexity.ai 就夠嗎？

對多數「從瀏覽器走標準流量」的情境已能涵蓋主線，但只要日誌出現未命中的兄弟子域或 pplx.ai 類跳轉，就應增量補齊。請把規則檔視為活文件，而不是一次寫死即永遠正確。

Perplexity 和 ChatGPT、Gemini 可否共用同一策略組？

技術上可以，但不建議：出口品質與站方策略不盡相同，混在一起會讓你在除錯時難以判斷是「規則錯」還是「單一服務挑節點」。本站已為不同供應商分篇整理網域，與本篇並讀即可拼出完整的地圖。

免費訂閱連結與設定檔如何取得？

本站建議透過官方下載頁面取得客戶端，並以提供方給予的免費訂閱連結更新節點；請勿將來路不明的 YAML 直接貼入全系統網路。若你要在學習用的最小範例上測試，可先從下載中心取得適合的平台版本，再逐步合併規則模組。

可帶走的自檢清單（2026 實務向）

  1. 確認核心為 Clash Meta（mihomo）或你慣用分支，且設定檔可成功載入。
  2. 為 perplexity.ai、pplx.ai 建立獨立策略組引用，並將分流規則置於兜底條目之前。
  3. 開啟連線日誌，實際送出一則 prompt，核對核心請求主機名是否完整覆蓋。
  4. 若使用 Rule Providers，檢查合併順序，避免廣義條目搶先命中。
  5. 排除 DNS 與本地安全軟體因素後，再於同一策略組內調整節點。

養成「日誌先行、規則次之、節點最後」的習慣，你在面對不斷演進的 AI 搜尋介面時，比較不容易落入「頻繁重裝客戶端卻找不到根因」的循環。

寫在最後：把 Perplexity 收進可維護的分流模組

Perplexity 類服務把索引、推理與引用拆在多段連線上，只靠肉眼看到 perplexity.ai 不足以配置分流規則。把主線後綴、常見跳轉域與日誌中浮現的新子域拆開維護，並用清晰的策略組承載出口選擇，你會發現多數「總打不開」其實是規則覆蓋與順序問題，而不是神秘阻斷。

若你希望用圖形介面管理訂閱、檢視命中規則並內建現代核心，可優先從下載中心取得對應系統的 Clash 客戶端，省去手動拼湊的時間；取得節點後再以免費訂閱連結更新，與本文骨架合併即可。

→ 立即免費下載 Clash 客戶端，以視覺化訂閱與連線日誌管理 Perplexity 相關分流規則，讓策略組命中與節點切換一目了然

延伸閱讀可回到技術專欄挑選其他主題；若要系統化掌握規則全貌，亦建議搭配YAML 規則指南與Meta 核心升級教學一併服用。