Perplexity 打不開怎麼辦？用 Clash 排查連線逾時

Perplexity 無法開啟、一直顯示「連線逾時」或頁面載入到一半停止，未必代表網站本身故障。當流量經過 Clash 時，代理模式、節點可用性、DNS 解析、分流規則與瀏覽器連線狀態任何一個環節出現問題，都可能讓 Perplexity 看起來像是完全無法使用。本文以 Clash Verge、Clash Verge Rev、Clash for Windows、ClashX、Clash for Android 與 Mihomo 都適用的思路，提供由淺入深的排查流程，協助你快速判斷問題究竟出在哪一層。

先判斷問題發生在哪一層

排查連線逾時時，最忌諱一開始就大幅修改 YAML。更有效率的方式，是先把問題拆成「網站本身」「本地網路」「Clash 核心」「代理節點」與「瀏覽器」五個層次。你可以先關閉 Clash，直接用目前的網路開啟其他一般網站，再嘗試開啟 Perplexity。如果所有網站都載入緩慢，問題可能來自 Wi-Fi、路由器、DNS 或網路服務商；如果只有 Perplexity 失敗，而其他網站正常，才需要優先檢查代理與規則。

接著重新啟用 Clash，先不要使用複雜的規則模式，將模式暫時切換為 全域（Global），並在代理頁面手動選擇一個延遲較低、最近測速成功的節點。這一步的目的不是要求你長期使用全域代理，而是排除規則匹配錯誤。若全域模式可以開啟 Perplexity，而規則模式不行，通常表示問題集中在規則集、策略組或 DNS；若全域模式也逾時，則要繼續檢查節點、TLS、TUN 或核心狀態。

1. 確認 Clash 核心正在執行，而不是只有客戶端介面開啟。
2. 確認系統代理已啟用；使用 TUN 模式時，確認虛擬網卡沒有被系統停用。
3. 將模式切換為全域，選擇一個可以完成延遲測試的節點。
4. 重新開啟無痕視窗，造訪 https://www.perplexity.ai。
5. 如果仍然失敗，再查看 Dashboard 中的連線記錄與命中規則。

檢查代理模式與節點狀態

Perplexity 的登入、搜尋與答案生成通常會建立多條 HTTPS 連線，部分功能還會依賴額外的 API 或長連線請求。因此，節點「可以測速」不一定代表它能穩定完成整個使用流程。某些節點可以快速回應測速網址，卻在連線到特定海外服務時被限速、重置或中途丟包，最後就會表現為瀏覽器逾時。

在 Clash 的代理頁面中，先觀察目前策略組是否顯示錯誤、不可用或延遲異常。如果使用的是 url-test 或 fallback，自動選出的節點不一定是 Perplexity 最適合的節點。可以暫時改用手動選擇，依序測試兩至三個不同地區的節點。每次切換後，等待幾秒讓舊連線關閉，再用無痕視窗重新測試，避免瀏覽器沿用原本失敗的連線。

• 所有海外網站都無法開啟：優先檢查節點是否失效、訂閱是否過期、系統時間是否正確，以及本地網路是否封鎖代理連線。
• 只有 Perplexity 逾時：檢查 Perplexity 相關域名是否被錯誤分流，並確認該節點沒有對特定服務限速。
• 首頁能開但搜尋或登入失敗：可能是相關 API、驗證服務或長連線域名沒有走同一個代理策略。
• 切換節點後立即恢復：原節點可能存在出口 IP 受限、DNS 異常或跨境線路丟包問題，不必急著修改整份配置。

如果你使用的是 rule 模式，建議透過 Dashboard 的 Connections 頁面搜尋 perplexity，查看實際連線命中了哪條規則、使用了哪個策略組。理想情況下，相關連線應該穩定地進入代理策略，而不是被 DIRECT、拒絕策略或錯誤的國內節點接管。

確認分流規則沒有把流量送錯

分流規則是最常見、也最容易被忽略的原因之一。規則通常由上到下匹配，前面較寬泛的規則可能在 Perplexity 專用規則之前就已經生效。例如，某條 GEOIP,CN,DIRECT 或自訂的 DOMAIN-SUFFIX,ai,DIRECT 規則，可能讓請求直接連線；也有些配置將未知域名交給 FINAL,DIRECT，導致新增加的服務沒有經過代理。

Perplexity 不一定只使用一個主域名。實際請求可能涉及主站、登入、靜態資源、API、驗證與分析服務。你不需要盲目把所有包含關鍵字的域名都加入代理，但可以先用連線記錄找出真正失敗的目標，再建立範圍有限的規則。以下範例適合用來測試，實際使用時請把策略組名稱替換成你的配置名稱：

rules:
  - DOMAIN-SUFFIX,perplexity.ai,Proxy
  - DOMAIN-SUFFIX,pplx.ai,Proxy
  - DOMAIN-SUFFIX,perplexity.com,Proxy
  - MATCH,自動選擇

測試時要注意三個細節。第一，Proxy 與 自動選擇 必須是配置中實際存在的策略組名稱，大小寫與符號都要一致。第二，Perplexity 專用規則要放在可能匹配到它的廣泛規則之前。第三，修改配置後要重新載入配置或重啟核心，部分客戶端不會自動套用檔案中的變更。

如果你使用 Rule Provider，還要確認規則集本身已成功下載。Provider 更新失敗時，客戶端可能仍然使用舊版本，甚至在重新啟動後恢復成空規則。可在 Dashboard 中查看 Provider 的更新時間與錯誤訊息。排查期間可以暫時用兩三條直接寫在 rules 下方的測試規則，藉此判斷是規則內容問題，還是節點與 DNS 問題。

排查 DNS 解析與 fake-ip

若連線記錄中出現域名解析失敗、找不到主機、反覆重試，或瀏覽器顯示 ERR_NAME_NOT_RESOLVED，應該把重點放在 DNS。普通模式下，瀏覽器可能先向系統 DNS 詢問真實 IP，再把 IP 交給 Clash；如果 DNS 回應遭到污染、回傳不可達地址，Clash 甚至還沒開始選擇代理節點，連線就已經失敗。

對 Mihomo 與支援增強 DNS 的 Clash 核心而言，fake-ip 通常更適合需要按照域名分流的場景。它先回傳虛擬 IP，再由 Clash 根據域名對應表決定代理或直連，可以避免應用程式過早取得錯誤的真實 IP。以下是一個偏向排查用途的簡化配置：

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  fallback-filter:
    geoip: true
    geoip-code: TW

這段配置不代表所有網路環境都應該照抄。若你所在的網路無法連線到某個 DoH 服務，使用它反而會增加逾時。可以先保留一個穩定的上游，確認 Perplexity 能否開啟，再逐步加入備用 DNS。若你已經切換過 fake-ip，記得清除 DNS 快取並重新啟動瀏覽器；部分應用會長時間保留舊的解析結果。

在啟用 TUN 模式時，也要確認 dns-hijack、虛擬網卡與系統 DNS 沒有互相衝突。Windows 可以先停用再重新啟用 TUN；macOS 可重新切換系統代理；Android 則要檢查「私人 DNS」是否與 Clash 的 DNS 接管功能同時生效。不要在不了解影響的情況下同時啟用多個 DNS 攔截器，否則會出現偶爾成功、偶爾逾時的間歇性問題。

檢查 TLS、TUN 與瀏覽器狀態

如果 DNS 正常、節點測速成功、規則也確定命中代理，但 Perplexity 仍然顯示連線逾時，就要檢查 TLS 握手與流量接管方式。首先確認作業系統日期、時間與時區正確。TLS 憑證驗證依賴本機時間，時間偏差過大時，瀏覽器可能將正常憑證判定為尚未生效或已過期。

其次，檢查節點配置中的伺服器名稱指示（SNI）、TLS 選項與憑證驗證。除非你正在處理明確的自簽憑證測試環境，否則不建議長期開啟 skip-cert-verify: true。它有時能暫時繞過憑證錯誤，但無法修復錯誤的伺服器地址、SNI 或節點本身不可用的問題，還會降低連線安全性。

• 系統代理模式：適合瀏覽器等遵循系統代理的應用，但不一定能接管所有程式。
• TUN 模式：可以接管更多不支援系統代理的應用，但需要正確的驅動、權限、路由與 DNS 設定。
• 瀏覽器擴充功能代理：可能覆蓋 Clash 的系統代理，造成瀏覽器與其他應用使用不同出口。
• 企業網路或校園網：可能限制 UDP、QUIC 或未知 TLS 流量，可嘗試更換支援 TCP/443 的節點。

瀏覽器方面，建議先開啟無痕視窗測試，避免擴充功能、Service Worker、快取或既有 Cookie 影響結果。若無痕視窗正常，而一般視窗逾時，可以清除 Perplexity 相關網站資料，並暫時停用廣告攔截、隱私保護或代理切換擴充功能。若使用 Chromium 系瀏覽器，也可以關閉該站點的 HTTP/3 或 QUIC 測試，以排除網路對 UDP 流量限制造成的問題。

一套可重複使用的修復流程

當你不確定問題在哪裡時，可以依照以下順序恢復設定。這套流程的重點是先回到最簡單、最容易觀察的狀態，再逐步加入原本的功能，不需要一次重建整份配置。

1. 記錄目前的配置檔案，避免修改後無法還原。
2. 更新訂閱並確認至少有兩個節點可以完成測速。
3. 切換到全域模式，手動選擇一個節點測試 Perplexity。
4. 若全域模式成功，切回規則模式，檢查 Connections 中的實際命中規則。
5. 補上必要的域名規則，並將它放在廣泛規則之前。
6. 若仍逾時，清除 DNS 快取，重新啟動 Clash 核心與瀏覽器。
7. 在 fake-ip 與 redir-host 之間測試，確認是否為 DNS 模式造成。
8. 最後才檢查 TUN、HTTP/3、TLS 驗證與瀏覽器擴充功能。

修復後不要只測試首頁。請分別測試首頁載入、登入、輸入問題、取得答案，以及重新整理頁面等操作。某些設定只足以載入靜態頁面，卻無法維持後續 API 請求；只有完整走完幾個流程，才能確認問題真正解決。

如果所有節點都無法使用，而其他代理服務也同時逾時，可能是當前網路環境或節點服務商的共通故障。此時可以換一種傳輸協議或網路環境交叉測試，例如使用手機熱點與家用網路各測一次。若只在單一裝置發生，優先檢查該裝置的系統代理、DNS、時間與安全軟體；若所有裝置都發生，則更可能是節點、訂閱或上游網路問題。

總結來說，Perplexity 打不開時，不要只反覆點擊重新整理，也不要一開始就大量加入規則。先用全域模式確認節點，再透過連線記錄確認規則，接著檢查 DNS 與 TUN，最後處理瀏覽器和 TLS 細節，通常就能把「連線逾時」拆解成可定位、可修正的具體問題。完成排查後，再切回適合日常使用的規則模式，保留簡潔且容易維護的配置。