為何 Perplexity 網頁版與 Pro「看似能開卻不穩」

Perplexity 這類 AI 搜尋產品在單一瀏覽器分頁裡，往往同時打向主站、內容 CDN、帳戶與實驗功能、以及訂閱與金流等第三方服務。任何一條 TCP/TLS 連線走到錯的出路，表面症狀都很像：搜尋問句送出後轉圈、網頁版能進首頁但帳戶頁 403、Perplexity Pro 剛顯示升級成功卻在下一則提問被收回權限。跨境網路下，若 Clash 分流用過寬的 GEOIP 命中，或 url-test 策略組在長連線中頻繁切換，主機就會在「直連、代理、不同地區的代理」之間漂移。

與其一口氣怪罪「節點壞了」，更務實的做法是把問題拆成三層：一、規則有沒有寫在對的順序，讓 Perplexity 相關網名落在預期策略；二、出口是否用固定節點，避免工作階段中換 IP；三、名稱層面是否一致，讓 DOMAIN 規則看到的名字與實際 SNI、DNS 回傳沒有錯位。站內 連線日誌與規則命中一文可幫你對照「實際命中了哪一條規則」。

💡
與他篇的界線 ChatGPT／OpenAI 路由見 此篇，Claude 見 此篇，Grok 與 X 見 Grok 分流。本文專注 Perplexity 常見主機分岔與 Pro／訂閱情境，避免標題關鍵字與上述文章重疊。

三種存取面：主站、帳戶與金流、Pro 能力

實作Clash 分流時，建議在腦中先劃出三條管線。第一條是主要對話與搜尋 UI，多半落在 perplexity.ai 與其靜態資源、API 子網域。第二條是登入、工作階段、裝置管理，可能牽涉通用身分供應商或郵件驗證，主機名稱有時與產品主域不同。第三條是Pro／付費，除產品站內升級外，也常有付款頁、收據與風控，落地在不同網域上。

產品迭代會讓清單隨版本改變，因此靜態抄一份「全網域表」不如以連線日誌為準：在出問題的當下篩出與 Perplexity 操作有關的主機名，再反向補上 DOMAIN／DOMAIN-SUFFIX 規則。注意不要把整個 *.cloudflare 之類超大後綴一次塞進高優先層，否則會與遊戲、網銀等其他服務衝突；寧可先精準、再觀察記錄漸進擴充。

YAML 範例：主站與「帳單／驗證」策略組分離

以下為觀念示範，節點與訂閱名稱請改為你環境中的實際值。重點是兩套策略組，讓搜尋與帳戶／金流可以選不同地區的穩定出口，卻不混在同一個會自動搖擺的 url-test 裡。

proxy-groups:
  - name: PPLX-APP
    type: select
    proxies:
      - US-PPLX-STABLE
      - JP-PPLX-STABLE
      - DIRECT
  - name: PPLX-ACCT
    type: select
    proxies:
      - US-BILLING-STABLE
      - US-PPLX-STABLE
      - DIRECT

rules:
  - DOMAIN-SUFFIX,perplexity.ai,PPLX-APP
  - DOMAIN-SUFFIX,pplx.ai,PPLX-APP
  # After logs confirm hostnames, add auth / billing / CDN rows above GEOIP, for example:
  # - DOMAIN,accounts.example.com,PPLX-ACCT
  # - DOMAIN-SUFFIX,stripe.com,PPLX-ACCT
  # - GEOIP,CN,DIRECT
  # - MATCH,GLOBAL

訂閱產生的規則若會覆寫你手寫的段落，可用 Clash Meta 覆寫 的 prepend-rules 或等效合併層，把 Perplexity 專用行固定在清單前段。寬鬆的國內直連、海外代理骨架則參考 分流規則教學，再把本文這層當成疊在上方、較具體的補充。

規則優先順序：寬泛規則不應攔在 DOMAIN 之前

使用者最常碰到的雷，是 GEOIP,xx,DIRECT 或「全流量 MATCH 到一個大策略組」寫在檔案前段，導致與 Perplexity 網頁版相關的請求被提早吸走。表面上瀏覽器仍「打得開一個殼」，但內嵌請求與驗證卻從 DIRECT 與「代理路徑」兩邊分頭進行，登入與 Pro 權限就會在邊界上抖動。解法很單純：把針對服務的 DOMAIN／DOMAIN-SUFFIX 行，放在寬泛規則與地區直連條文之前，並在改動後用日誌確認每一條連線的「策略名＋實際節點」都符合預期。

若你使用多份規則片段或 Provider，也請留意合併後的實際順序；看見的 YAML 檔與執行時拼起來的順序不是永遠一致——這就是為什麼要用連線層的命中結果驗證，而不是只憑肉眼掃一輪檔案。

固定節點與 2026 仍適用的實務原則

間隔很短的 url-test 或健康檢測導向的自動切換，對長流式回應、驗證 Cookie、以及風控場景都極不友善。中間若換了出口 IP，服務端可能當成新的風險裝置，你會看到帳戶被重新挑戰、或 Perplexity Pro 權限短暫丟失。除錯階段最穩的是：在 select 裡手動點一顆你確認能用的節點，整段操作都別換；等行為可重現的「不穩定」消失後，再考慮改成較寬鬆的 fallback 並拉長測量間隔。

在 2026 的實務共識仍是：與帳戶、付款有關的管線，優先和「主對話管線」用同一地區的固定節點，避免同一個瀏覽器工作階段裡，搜尋走東京、帳戶卻走洛杉磯這類分岔。要驗證是否為「切節點造成」，只要對照日誌中失敗前後的節點名稱是否變化即可。

DOMAIN、SNI 與 fake-ip：讓名稱與路徑對齊

fake-ip 下，你看到的「解析結果」與實際 TLS 連線的目的名稱不總是直覺一對一；若同時啟用瀏覽器內建安全 DNS、或本機還有別的 DNS 客戶端，更容易出現雙解析器。建議在排障期暫關瀏覽器安全 DNS，讓 Clash 成為單一權威入口，再觀察症狀是否緩解。名稱與模式更詳盡的對比可讀 fake-ip 與 redir-host。

HTTPS 連線的 ClientHello 會帶 SNI。若中間有企業掃描、本機攔截軟體、或衝突的擴充套件，SNI 與實際路由層看見的主機名可能脫節，規則怎麼寫都會「有時中、有時不」。可先用最小化環境測：只留 Clash、關掉同類代理與攔截，確認問題是出在代理策略還是作業系統／瀏覽器外層。

TUN 與系統代理：瀏覽器與 App 要同一條管線

只開系統代理時，UWP 與少數二進位程式可能仍繞路；TUN 模式 則讓多數流量進同一個規則表。若你從 PWA 或桌面殼層啟動 Perplexity 網頁版，卻在另一個終端裡用未設代理的 CLI 測速，兩邊觀測到的不一致是預期現象。統一管線之後，再回頭看 DOMAIN 與節點，才不會被「其實沒有走 Clash」誤導。

分症狀排障表

查日誌中與提問、串流相關的主機是否都命中 PPLX-APP（或你定義的應用策略），並確認該段時間節點沒有反覆切換。暫改手動 固定節點重試；若隨即正常，幾乎可判定是搖擺或規則漏接而非單一節點故障。

Pro 顯示開通、下一則提問又變成免費

典型是帳戶／權限 API 沒有與主流量走同一路。把日誌裡帶有 subscription、entitlement、billing 等字樣的主機一併納入 PPLX-ACCT 或與 PPLX-APP 同區同節點，再觀察是否仍抖動。仍不行時，清 Cookie 前務必先固定出口，否則風險偵測只會加劇。

升級到一半付費頁打不開

單獨補上付款相關網名到帳戶策略組，並注意不要在不明確的情況下把整條 DOMAIN-SUFFIX,某支付網,PROXY 拉得過寬。若牽涉到裝置簡訊與 3D 驗證，有時還要短暫改走與帳單地區一致、且沒有頻跳的健康節點。

小結

把 Perplexity 的主應用與帳戶／金流拆成可獨立選路徑的策略組，把 DOMAIN 層的規則擺在寬泛規則與 GEOIP 之前，再以固定節點壓平出口抖動，就能對應到多數「網頁版能開、Pro 卻不穩」的實戰狀況。名稱層上則要確認 DNS、fake-ip 與 SNI 沒有互相打架；證據一律從連線日誌與規則命中來，而不是只猜測訂閱有沒有過期。若你尚未安裝用戶端，可先從 下載頁面 取得合適的客戶端，並依 訂閱匯入教學 匯好節點與基礎規則，再疊加本文的 Perplexity 專屬分流。→ 免費下載 Clash，讓 Perplexity 與 Pro 權限走在同一條可預期的路徑上