前言：為什麼 Perplexity 會逾時？
Perplexity 突然無法連線、搜尋頁面一直載入，或登入後反覆回到首頁，並不一定代表服務本身故障。對使用 Clash 的用戶來說，問題也可能出在目前的工作模式、分流規則、DNS 解析、節點品質，甚至是瀏覽器殘留的登入狀態。尤其 Perplexity 不只需要開啟主頁，還會同時連線到 API、驗證服務、靜態資源與串流回應伺服器；其中任何一個網域走錯路徑，都可能表現為「逾時」或「頁面載入不完整」。
本指南會按照由簡到難的順序，帶你確認網路、Clash、節點與瀏覽器環境。無論你使用的是 Clash Verge、Clash Verge Rev、Clash for Windows、ClashX、Clash for Android 或 Mihomo，都可以依照相近的思路操作。重點不是盲目切換大量節點，而是先找出到底是整體代理失效、Perplexity 規則未命中，還是特定節點無法完成長連線。
排查目標
確認 Perplexity 的網域經過正確策略組、DNS 不被錯誤解析，並選擇能穩定支援 HTTPS 與串流回應的節點。
1先判斷逾時來源
開始修改配置前，先記錄錯誤出現的具體位置。不同現象通常對應不同原因：如果整個網站完全打不開，優先檢查代理模式、節點與 DNS；如果首頁可以開啟，但搜尋送出後轉圈，則要注意 API 網域、規則匹配和節點是否支援長時間連線；如果結果已經出現，卻無法逐字串流顯示，可能是節點品質不穩或連線被中途重置。
- 首頁完全無法開啟：確認 Clash 是否正在運行，系統代理是否指向正確的 HTTP 或 SOCKS 埠。
- 搜尋提交後逾時：檢查 Perplexity 相關網域是否被規則送往
DIRECT，或是否誤套用了拒絕規則。 - 登入頁面循環跳轉：清除該網站 Cookie，並確認驗證服務與主站使用同一個穩定地區的節點。
- 結果載入一半中斷：測試其他節點，避免使用高延遲、頻繁重連或限制 WebSocket 的線路。
- 只有單一設備故障：比較手機與電腦的 Clash 配置，通常是本機 DNS、TUN 權限或瀏覽器設定差異。
先不要頻繁切換帳號
連續重新登入、快速更換多個國家或地區的節點，可能讓驗證系統判定環境異常。排查時請固定一個節點測試數分鐘，再比較其他線路。
三個基礎測試
先暫停瀏覽器擴充功能，使用無痕視窗開啟 Perplexity，並分別測試「Clash 關閉」與「Clash 開啟」的結果。若兩種狀態都無法連線，問題可能是本地網路、服務端或帳戶狀態；若只有開啟 Clash 後失敗，才需要集中檢查配置。你也可以用瀏覽器開發者工具的 Network 面板觀察失敗請求，留意是 DNS error、502、403，還是單純等待時間過長。
2檢查 Clash 模式與節點
Clash 的「規則」模式會根據配置決定流量去向，而「全域」模式則會將大多數流量交給目前選定的代理組。排查 Perplexity 逾時時，可以短暫使用全域模式作為對照測試，但不建議長期依賴全域代理。若全域模式可以使用、規則模式卻逾時，幾乎可以確定是規則順序、策略組或 DNS 行為需要調整。
選擇穩定節點，而不是只看延遲
節點延遲低不代表一定適合 Perplexity。ICMP 測試只反映基本封包往返時間，無法代表 HTTPS 握手、TLS 建立和串流回應的實際表現。建議先挑選距離較近、出口穩定、晚間不會大幅降速的節點，再觀察完整搜尋是否成功。測試期間不要啟用會自動輪換 IP 的負載均衡組，否則一次搜尋的不同請求可能被分配到不同出口，導致驗證失敗或連線中斷。
- 先使用固定節點測試首頁、登入和一次完整搜尋。
- 再比較兩至三個不同地區節點，記錄 TLS 握手速度與結果串流是否完整。
- 若某節點只有首頁可用，搜尋時逾時，將它從 Perplexity 專用策略組移除。
- 確認代理服務仍有流量額度，且訂閱中的節點沒有過期或被服務商停用。
確認分流規則與策略組
在配置檔案中，Perplexity 相關規則應放在一般的地理位置規則、兜底規則之前，避免先被 GEOIP、GEOSITE 或 MATCH 攔截。以下是一個用於排查的簡化寫法；其中 Perplexity 必須替換成你實際配置中的穩定策略組名稱：
規則名稱與策略組名稱必須完全一致，大小寫和空格也不要任意更改。修改後請儲存配置並重新載入，而不是只重新整理瀏覽器。如果 Clash Verge Rev 或 Mihomo 顯示規則解析錯誤，先還原最後一次修改，再逐行加入規則，這樣較容易找到 YAML 縮排或標點問題。
3動手操作：逐步修復 Perplexity 逾時
- 開啟 Clash Verge 或 Clash Verge Rev，確認核心狀態為正在運行，並記下目前的 HTTP、SOCKS 或混合埠。
- 暫時切換到「全域」模式，選擇一個固定節點，關閉自動選擇與負載均衡。
- 在瀏覽器無痕視窗開啟 Perplexity，先測試首頁，再登入並送出一個簡短問題。
- 若全域模式成功，切回「規則」模式，檢查連線記錄中
perplexity.ai、pplx.ai的匹配策略。 - 把關鍵網域規則放到兜底規則之前，重新載入 YAML，然後再完成一次搜尋測試。
- 確認 Clash for Android 或 Mihomo Party 已取得 VPN 權限，並檢查是否被省電模式強制停止。
- 若使用 TUN 模式，測試一次「系統代理」或相反模式，排除虛擬網卡與其他 VPN 應用衝突。
- 關閉私人 DNS、其他廣告攔截 VPN，以及瀏覽器內置的代理功能，避免多層代理互相搶占連線。
- 清除 Perplexity 應用或瀏覽器的網站資料，重新連接固定節點後再測試。
小撇步
每次只修改一項設定，並保留「修改前可用的配置」備份。若改動模式、DNS 和規則後才測試，很難判斷真正有效的修復原因。
4DNS、TUN 與瀏覽器的進一步檢查
如果規則已命中、節點也能連線，仍然出現逾時，就要檢查 DNS。Clash 可能採用系統解析結果，也可能使用自身的 DNS 模組；若本地 DNS 回傳錯誤地址、遭到污染，或 IPv6 路徑品質不佳，瀏覽器便可能在連線階段長時間等待。Mihomo 使用者可以在 DNS 設定中確認是否啟用合理的遠端解析方式，並避免同時疊加多個不明來源的 DNS 覆寫配置。
- 清除舊解析：修改 DNS 後重啟 Clash，必要時重新啟動瀏覽器與系統網路。
- 檢查 TUN 權限：TUN 模式需要系統管理員或 VPN 權限；權限不足時，部分應用流量可能完全繞過 Clash。
- 留意 IPv6：若 ISP 的 IPv6 連線不穩，可暫時停用 IPv6 或確認 Clash 能正確接管 IPv6 流量。
- 避免雙重代理：不要同時啟用瀏覽器代理擴充功能、系統 VPN 與 Clash TUN，除非你清楚每一層的用途。
處理登入循環與快取問題
登入異常不一定是節點問題。瀏覽器可能保存了過期 Cookie、錯誤的地區資訊或被阻擋的第三方驗證資料。請先只清除 Perplexity 網站的 Cookie 和快取，再使用無痕視窗測試；不要一開始就刪除所有瀏覽資料。若無痕視窗正常，逐一停用廣告攔截、腳本阻擋和隱私防護擴充功能，找出造成驗證頁面無法完成的項目。
何時應該停止修改配置？
如果多個可靠網路、不同瀏覽器和固定節點都出現相同錯誤，可能是 Perplexity 正在維護、帳戶受到限制，或服務端暫時拒絕目前出口 IP。此時應先查看官方狀態資訊，等待一段時間後再測試；不要不斷重試或編寫大量繞過驗證的規則。代理工具只能改善本地連線路徑，無法保證第三方服務在任何地區、任何帳戶狀態下都能正常使用。
總結：建立可復用的排查流程
面對 Perplexity 逾時，最有效的方法是依序確認：Clash 是否運行、節點是否穩定、全域模式能否建立對照、規則是否命中、DNS 是否正確，以及瀏覽器是否存在快取或擴充功能干擾。完成修復後，建議保留一個穩定的 Perplexity 策略組，避免使用頻繁切換出口的自動組；同時將修改後的 YAML 備份，日後訂閱更新時可以快速比對規則是否被覆蓋。
若你使用的是不同客戶端，介面名稱可能略有差異，但核心原理相同：先縮小問題範圍，再一次只改一個變數。這樣不但能解決本次載入失敗，也能讓未來處理其他網站的 Clash 連線問題時，有一套清晰、可重複的判斷方法。