C1 / 完全無法上網
無法上網:三刀切出問題層
開了 Clash 之後所有網站都打不開,先別急著換節點。病因大概率只有三類:本地線路本身斷了、節點全掛了、規則把流量送錯了地方。三刀切下去,十分鐘內一定能把問題定位到某一層。
第一刀:退出代理,測本地線路
關閉系統代理或直接退出客戶端,用瀏覽器造訪一個平時秒開的台灣本地網站。打不開,說明問題出在本地網路,和 Clash 一點關係沒有——先修 Wi-Fi、路由器或寬頻。能打開,說明線路正常,進第二刀。
這一步經常被跳過,然後對著客戶端修一下午,最後發現是路由器欠費重啟。先切直連,永遠是排查代理問題的第一動作。
第二刀:切全域,排除規則
把客戶端切到全域模式(GLOBAL),手動選一個平時表現穩定的節點,造訪需要代理的目標站點。通了,說明節點沒問題,問題在規則分流——切回規則模式,進第三刀。不通,說明問題在節點側或本地入站,直接跳到 C2 節點超時繼續。
全域模式只是排查手段
定位完記得切回規則模式。一直掛全域,台灣本地流量也繞地球一圈,速度和流量都虧。全域與規則模式的取捨,
疑難解答裡有單獨一條。
第三刀:開日誌,看規則命中
在設定裡把日誌級別調高,然後在客戶端的連線/日誌面板裡觀察:目標網域被哪條規則命中、送進了哪個策略群組、策略群組當前選的是誰。常見翻車現場有兩個:兜底的 MATCH 規則指向了 DIRECT,該代理的流量全體直連;或者某條 DOMAIN-SUFFIX 寫得太寬,把不該直連的網域劫去了直連。
# config.yaml:排查期把日誌調詳細,修完再調回去
log-level: debug
mode: rule
懷疑核心根本沒起來?用命令直接戳本地入站連接埠(埠號以你設定裡的 mixed-port 為準):
curl -x http://127.0.0.1:7890 -I https://www.gstatic.com/generate_204
期望回傳 204。連 curl 都不通,說明核心沒在監聽——不是設定連接埠寫錯,就是程序根本沒啟動,跳到 C7 崩潰閃退。
三刀之外:兩個容易被忽略的入站陷阱
三刀切完還是不通,再看兩處入站細節。第一處是監聽地址:多數設定預設只在 127.0.0.1 上監聽,本機自己用沒問題,但你若在另一台裝置上填了這台機器的區域網路 IP 當代理,請求會被直接拒絕,現象是「客戶端明明連著,另一台電腦卻完全打不開網頁」。要給區域網路共用,得把 allow-lan 打開,並確認 bind-address 沒有把可存取範圍鎖死。
第二處是連接埠協定對不上。mixed-port 同時接受 HTTP 與 SOCKS5 兩種入站,是最省心的寫法;如果設定裡只寫了 socks-port,而瀏覽器擴充功能按 HTTP 代理去連它,交握階段就直接失敗,報錯長相和「核心沒啟動」幾乎一模一樣。排查時先確認你填進去的那個連接埠到底提供哪種協定,再懷疑別的。
# config.yaml:一個連接埠全都收,省掉大半協定錯配問題
mixed-port: 7890
allow-lan: false
還有一種隱形故障值得單獨點出來:同一台機器上先後裝過兩個代理客戶端,另一個還在背景監聽同一個連接埠。此時你連上的其實是另一個軟體,規則怎麼改都不生效,日誌裡也看不到任何請求進來。C7 章的連接埠占用查法同樣適用於這個場景,查出占用程序後把多餘的那個徹底關掉再重試。
C2 / 節點超時
節點超時:全紅和零星紅是兩種病
延遲測試一片紅,先分型:所有節點全部超時,和個別節點超時,病因完全不同。全紅多半是你這一側的問題;零星紅才是節點自己的問題。
全部超時:先查自己這一側
- 訂閱過期或流量用盡。登入服務商後台確認套餐狀態。這是全紅榜單上的第一大戶,查它花十秒,值得排第一。
- 測速連結本身被擋。延遲測試用的 URL(常見是
generate_204 一類)如果在目前網路裡被擋,所有節點都會顯示超時,但實際都能用。換一個測速 URL 再測一輪,數字全回來了就是這個原因。
- 本地防火牆擋了核心。Windows 首次啟動時的防火牆放行彈窗點了「拒絕」,之後核心發不出封包,全部超時。到防火牆的應用程式放行清單裡把核心程序放行。
- 系統時間偏差過大。部分加密協定對本機時間敏感,誤差超出容忍範圍時,交握直接失敗。開啟系統時間自動同步,校準後重測。
個別超時:節點自己的事
單個節點長年紅,多半是伺服器下線或線路劣化,換節點即可。某個地區的節點集體紅,通常是該條國際線路故障或維護,等一等或換其他區域的節點。個別超時不值得修,值得換。
| 現象 | 大概率原因 | 處理 |
|---|
| 全部節點超時,後台顯示套餐正常 | 測速 URL 被擋或防火牆擋核心 | 換測速 URL;放行核心程序 |
| 全部超時,瀏覽器還提示憑證錯誤 | 系統時間偏差 | 開啟時間自動同步 |
| 某地區節點整排紅 | 線路故障 | 換區域,或等線路恢復 |
| 數字正常,實際連不上 | 規則送錯出口 | 回 C1 第三刀看日誌 |
延遲數字怎麼讀
延遲測試測的是一次 HTTP 請求的往返耗時,不是頻寬。80ms 的節點可能跑不滿 10Mbps,200ms 的節點反而可能滿速——延遲決定「回應快不快」,頻寬決定「下載快不快」,兩碼事。想讓不同協定的節點延遲可比,可以開啟統一延遲:
# config.yaml
unified-delay: true
tcp-concurrent: true
自動測速策略群組裡的 url、interval、tolerance 三個參數各管什麼,部落格有一篇實測:url-test、fallback、load-balance 三種策略群組差異。
健康檢查的節奏也會製造「假超時」
自動測速群組會按 interval 週期性地對群組內每個節點各發一次測速請求。節點多、間隔短,客戶端就在持續製造大批短連線;在弱網、或者路由器工作階段表偏小的環境裡,這些並行探測本身就會互相擠占資源,反而讓延遲數字虛高,甚至整組一起顯示超時。訂閱裡有上百個節點時,把 interval 從預設的幾十秒放寬到 300 秒以上,數字往往立刻就乾淨了。
tolerance 是切換的防抖動閾值,單位是毫秒:只有當另一個節點比目前節點快出這個數值,才真的切換過去。設成 0,兩個延遲接近的節點會不停互搶,長連線被反覆重建,體驗上就是「網頁時不時斷一下、影片每隔幾分鐘緩衝一次」;設成 50 到 100,穩定性會明顯改善,代價只是有時沒選到理論上最快的那個。
還有一個容易誤判的細節:延遲列表裡的數字是上一次探測留下的結果,不是即時值。剛切換過網路環境(比如從 Wi-Fi 換到手機熱點)時,列表裡掛的可能還是舊網路下測出來的數字,紅綠都不作數。手動點一次「測試全部延遲」,等一輪探測跑完再判斷,比盯著舊值猜要靠譜得多。
C3 / 訂閱失敗
訂閱失敗:報錯文案就是病歷
訂閱拉不下來,客戶端拋出的報錯關鍵詞基本就說明了病因。先照表對號,再動手驗證。
| 報錯關鍵詞 | 含義 | 處理 |
|---|
404 / not found | 訂閱地址失效,或已被服務商重置 | 到服務商後台重新複製訂閱連結 |
timeout / 超時 | 訂閱網域在目前網路被擋,或介面回應慢 | 先用可用節點掛上代理再更新訂閱 |
403 / forbidden | 服務商限制了請求方的 UA | 按服務商要求的客戶端類型拉取 |
| invalid / yaml decode error | 拉到的內容不是合法設定 | 按下面的方法手動驗證內容 |
手動驗證訂閱到底回傳了什麼
客戶端的報錯有時候太含糊,直接用命令把訂閱拉到本地看一眼,一切都清楚了:
curl -sSL -A "clash.meta" "https://你的訂閱地址" -o sub.yaml
head -n 20 sub.yaml
前幾行應該是 YAML 結構(proxies:、port:、proxy-groups: 這類欄位)。如果看到的是 <html> 開頭,說明拉到了服務商的錯誤頁或攔截頁;如果是一整段沒有空格的長字串,說明回傳的是 base64 編碼的通用訂閱,需要經過訂閱轉換才能給 Clash 用。
訂閱轉換的取捨
轉換服務會經手你的訂閱地址,而訂閱地址等同帳號憑證。能用服務商原生提供的 Clash 訂閱,就不要轉;必須轉的,優先自建轉換服務,退而求其次也只用自己信得過的實例。轉換後節點全丟、策略群組錯亂,多半是轉換範本和訂閱格式不匹配,換範本重試。
訂閱地址 = 帳號憑證
別貼到群組裡,別填進來路不明的轉換站,別截圖帶連結。洩露了就去後台重設訂閱,舊連結立即作廢。
更新成功但節點沒變:快取與更新時機
另一類容易被當成「訂閱失敗」的情況是:更新顯示成功,節點列表卻還是舊的。先看客戶端裡顯示的訂閱更新時間有沒有前進,再看設定檔的修改時間。兩個都變了而節點沒變,那就是服務商那邊還沒把新節點寫進設定,和客戶端無關,等一等再更新。只有更新時間沒變的,才是客戶端真的沒拉取成功,常見原因是自動更新的定時任務在系統休眠期間被跳過,手動點一次即可。
反過來還有一種更隱蔽的:訂閱更新成功了,但你本地對設定做過手改(加了自己的規則、改了 DNS 段),更新時被服務商的原始內容整體覆蓋,於是「本來好的忽然又壞了」。想同時保留訂閱節點和自己的客製化,正確做法不是直接編輯訂閱產生的檔案,而是用客戶端提供的覆寫機制(Merge / Script / 覆寫設定這類功能)把自訂部分單獨放一份,讓它在每次更新後自動疊加上去。
更新頻率也別設得太激進。幾分鐘一次地拉訂閱,除了給服務商介面增加壓力,還容易觸發限流,回傳 429 或者乾脆被暫時封鎖,反而製造出「時好時壞」的假故障。一天一次,或者每次開機拉一次,對絕大多數人完全夠用。
C4 / 速度慢
速度慢:先立基準,再談優化
「慢」是最容易冤枉工具的症狀。不建立基準,一切優化都是玄學。先做兩次測速:一次直連,一次走代理。兩個數字的差值,才是代理鏈路引入的損耗。
基準怎麼讀
代理速度只有直連的三成以下,值得往下查;只差一兩成,那基本就是節點的物理極限——國際線路的頻寬本來就比本地寬頻貴得多,別指望代理測速追平直連。
三個常見瓶頸,按序排除
- 節點側:頻寬小、線路在晚高峰壅塞。換個時段測一次,白天快晚上慢,基本可以定性為線路壅塞,換節點或換套餐,本地怎麼調都沒用。
- 協定側:不同傳輸協定的開銷和抗干擾能力差異很大;UDP 被節點或線路限制時,視訊通話和部分依賴 QUIC 的應用程式會明顯退化。同一伺服器上換協定對比,或確認節點是否支援 UDP 轉發。
- 本地側:路由器上已經掛了一層代理、電腦上又開一層,雙重加密雙倍損耗;老舊裝置跑重加密協定 CPU 先到瓶頸。一層就夠,別疊羅漢。
核心側有兩個不花錢的開關值得打開:並行交握能壓低建線耗時,統一延遲讓測速更接近真實體驗:
# config.yaml
tcp-concurrent: true
unified-delay: true
高峰期慢的工程解法
手動換節點是戰術,策略群組是戰略。把常用地區的幾個節點編成一個自動測速群組,tolerance 設一個防抖動閾值,避免兩個節點延遲接近時來回橫跳:
proxy-groups:
- name: AUTO
type: url-test
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 50
proxies: [節點A, 節點B, 節點C]
大流量下載類場景可以考慮負載平衡群組把流量攤到多個節點上。三種策略群組類型怎麼選,看部落格實測:url-test、fallback、load-balance 差異。
測速方法本身也會騙你
很多「代理速度只有幾兆」的結論,其實是測法造成的。線上測速站會自動挑選距離最近的測速伺服器,而你的流量此刻從海外節點出去,測速站選的伺服器可能遠在節點所在地的另一端,來回繞兩趟,數字自然難看。判斷代理鏈路是否正常,更靠譜的做法是固定用同一個測速目標、同一個時段、同一個節點連測三次取中位數,只比較相對變化,不迷信絕對值。
瀏覽器裡的單執行緒下載也不適合當作頻寬結論。單條 TCP 連線的吞吐受延遲和封包遺失影響極大,高延遲鏈路上單執行緒跑不滿是物理規律;換成支援多執行緒的下載工具,同一個節點常常能翻好幾倍。要評估節點的真實上限,用多執行緒下載一個大檔案比刷測速網頁更接近實際。
分流做對了,慢的感覺會少一半
體驗上的「慢」很多時候不是頻寬不夠,而是本該直連的流量被送去了代理。本地的影音站、雲端硬碟、遊戲更新一旦繞到海外節點,速度必然崩;反過來,該走代理的網域落到直連上,則表現為長時間轉圈然後失敗。檢查規則順序時記住一條:規則是自上而下第一命中即生效,把範圍大的兜底規則寫在前面,後面精確的規則就永遠輪不到。
另一個常被忽略的開銷是 UDP。視訊通話、線上遊戲、部分依賴 QUIC 的網站都吃 UDP;節點不支援 UDP 轉發時,這些流量要麼退化成 TCP、要麼直接失敗,主觀感受就是「網頁還行,通話卡成幻燈片」。這類症狀不要往頻寬上找原因,先確認節點的 UDP 支援情況,再決定是換節點還是把 QUIC 相關流量單獨拒絕掉走回 TCP。
最後提醒一句取捨:本地能調的參數,總收益遠小於換一條好線路。把 tcp-concurrent、unified-delay 打開、把分流規則理順,該做;但反覆折騰核心參數期待翻倍提速,不現實。基準測出來差距懸殊的,直接換節點或換服務商更省時間。
C5 / DNS 問題
DNS 問題:一半的「玄學故障」都在這
DNS 故障的典型長相:有的網站秒開、有的永遠轉圈;代理明明連通,偵測站卻顯示解析出口是本地電信業者;換個節點某些站就好了、某些站又壞了。這些看起來隨機的現象,病根多半都在解析這一層。
兩種解析模式,先弄懂再調
Clash 系核心有兩種增強解析模式。redir-host 走傳統路線:先把網域解析成真實 IP 再比對規則,解析路徑長,容易在本地這一跳洩漏。fake-ip 則由核心直接回傳一個保留網段的「假地址」(預設 198.18.0.0/16),真實解析放到代理出口去做——建線更快,本地也不產生真實的明文查詢,是目前更推薦的預設選擇。
一份可以直接抄的 dns 設定
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "*.lan"
- "+.local"
nameserver:
- https://doh.pub/dns-query
fallback:
- https://1.1.1.1/dns-query
逐行說清:fake-ip-filter 是豁免名單,列出的網域不發假地址,留給區域網路裝置探索、印表機這類必須拿真實地址的場景;nameserver 走加密 DNS 處理常規解析;fallback 給海外網域兜底。兩組分工,別把所有網域都塞進同一個上游。
洩漏自查兩條路
代理連通不代表 DNS 沒洩漏。快的路:打開線上洩漏偵測站,看解析出口歸屬地是不是本地電信業者。硬核的路:本地封包截取,觀察 53 連接埠有沒有明文查詢直接出網。兩套手段的完整步驟和防洩漏寫法,部落格有一篇實作:Clash DNS 洩漏偵測與 fake-ip 防洩漏設定。
fake-ip 的副作用與解法
fake-ip 不是沒有代價:個別應用程式會把假地址快取下來,關掉 Clash 切回直連後,這些應用程式拿著 198.18 開頭的地址繼續撞牆,表現為「關了代理反而上不了網」。解法是重新整理系統 DNS 快取:
# Windows
ipconfig /flushdns
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
經驗法則
遊戲平台、區域網路投屏、NAS 這類對真實 IP 敏感的網域,統統加進 fake-ip-filter。豁免名單寧可寬一點,別讓印表機也去問代理要地址。
「有的站能開有的不能」的兩條典型病根
這個症狀幾乎總能歸到解析結果不對。第一條病根是上游分工錯了:把海外網域交給本地的加密 DNS 去問,拿回來的往往是就近的、或者被污染的地址,連上之後不是打不開就是內容錯亂。nameserver 負責常規與本地網域,fallback 負責海外網域,兩組各司其職,別圖省事只寫一組。
第二條病根是解析和出口不一致。網域在本地解析出一個本地 CDN 地址,流量卻從海外節點發出去,伺服器端看到的來源和解析結果南轅北轍,於是給你回傳一個存取不了的節點。fake-ip 模式天然緩解了這個問題——真實解析交給出口去做,解析與出口自然一致,這也是它比 redir-host 更推薦的核心原因之一。
改完 DNS 一定要重新驗證
DNS 設定改完不會馬上見效:系統快取、瀏覽器自己的內建快取、以及核心裡的解析快取都可能還留著舊結果。驗證順序建議固定成三步:重啟核心或重新載入設定,重新整理系統 DNS 快取,再關掉全部瀏覽器視窗重開。三步做完再測,才能確認改動到底有沒有生效,否則很容易把「快取沒清」誤判成「設定沒用」。
還要留意瀏覽器的加密 DNS 開關。Chrome 與 Firefox 都有內建的「安全 DNS / DNS over HTTPS」功能,一旦開著,瀏覽器會繞過系統與 Clash 自己去問網域,你在 config.yaml 裡寫的一切都被跳過,洩漏偵測也會顯示出意料之外的出口。做 DNS 排查時,先把瀏覽器這個開關關掉,把變數減到一個。
C6 / 系統代理不生效
系統代理不生效:告示不是執法
先說透原理:「系統代理」只是作業系統貼出的一張告示——「建議大家走 127.0.0.1 的這個連接埠」。應用程式可以看,也可以裝沒看見。瀏覽器一般看,終端從來不看,部分客戶端軟體有自己的主意。所以這一章必須分對象排查。
瀏覽器不走代理
- 確認瀏覽器的代理設定是「使用系統代理」。Firefox 預設用自己的代理設定,不讀系統的,需要手動指到
127.0.0.1 加對應連接埠。
- 代理類擴充功能會覆蓋系統設定。裝過 SwitchyOmega 一類擴充功能的,先停用再測——擴充功能裡殘留的舊規則是這一症狀的頭號嫌犯。
- 換個瀏覽器交叉驗證:A 瀏覽器通、B 瀏覽器不通,問題一定在 B 自己的設定裡,別再折騰客戶端。
終端不走代理
終端程式只認環境變數,不認系統告示。開著 Clash 用 curl、git、套件管理器照樣直連,是正常現象不是故障。給目前工作階段手動掛上:
# macOS / Linux(目前工作階段有效,連接埠以你的設定為準)
export https_proxy=http://127.0.0.1:7890 http_proxy=http://127.0.0.1:7890 all_proxy=socks5://127.0.0.1:7890
# Windows PowerShell
$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"
注意 git、docker 這類工具還有自己獨立的代理設定項,環境變數不一定全覆蓋,連不上時去各自的設定檔裡再確認一層。
TUN 模式:一次接管所有流量
不想逐個應用程式伺候,就上 TUN 模式:核心建立一塊虛擬網卡,在網路層直接接管全部流量,誰都別想裝沒看見告示。代價是需要管理員權限或系統授權,首次開啟會有安裝虛擬網卡的確認步驟。開了 TUN 之後建議關掉系統代理開關,避免流量被處理兩遍。瀏覽器與終端的完整分路排查記錄,見部落格:系統代理不生效的瀏覽器與終端分路排查。
TUN 也有它自己的失效方式。虛擬網卡裝好了但路由沒接管成功時,現象是「開了 TUN 跟沒開一樣」,多數發生在系統更新後驅動失效,或者裝置上還裝著別的 VPN 類軟體搶占了路由表——把其他 VPN 客戶端退乾淨,再重新開一次 TUN,大多能恢復。另一種是開了 TUN 之後區域網路裝置互訪失效,原因是區域網路網段的流量也被通道接管了,把內網網段加進直連規則即可。
代理開關看著開著,其實早被頂掉了
Windows 上系統代理是寫進登錄檔的一個全域設定,誰都能改。常見的頂掉場景有三種:另一個代理客戶端啟動時把它改成了自己的連接埠;某次異常退出沒有把設定清乾淨,殘留了一個已經沒人監聽的連接埠;企業裝置上的政策指令碼在登入時又把它刷回公司代理。判斷方法很直接——去系統的代理設定頁面,親眼確認地址和連接埠跟客戶端裡顯示的一致,而不是只看客戶端裡那個開關是不是綠的。
macOS 上則要注意「按網路服務分別設定」這件事:代理設定是掛在具體網卡上的,給 Wi-Fi 打開的代理,插上網路線用以太網路時並不生效。多網卡裝置上遇到「換了個上網方式代理就失靈」,先去網路偏好裡確認目前那張在用的網卡有沒有配上代理。
還有一個必須知道的例外:繞過清單。系統代理設定裡通常有一份「不使用代理的地址」清單,本機地址與內網網段預設在裡面。有人為了排查隨手往裡加過通用字元,之後就會出現「某些網域死活不走代理」的怪現象。這份清單是排查系統代理問題時必看的一欄,別只盯著連接埠。
C7 / 崩潰閃退
崩潰閃退:四步走,九成能救
客戶端打不開或者啟動秒退,九成落在三件事上:設定解析失敗、連接埠被占用、上次異常退出留下的核心殘留程序。按下面四步走,不要跳步。
第一步:看日誌
閃退不是沒有遺言,遺言都寫在日誌裡。從客戶端設定裡找「開啟日誌目錄」或「開啟應用程式目錄」,看日誌最後幾行。YAML 解析失敗會直接指出行號和欄位名,連接埠衝突會寫明 address already in use,照著報錯走,比瞎猜快十倍。
第二步:驗設定
用客戶端「新建空白設定」或恢復預設設定的功能啟動一次。能起來,說明問題在你的設定檔——回到日誌指出的行號修 YAML。高頻錯誤就三種:縮排混用了 Tab 和空格、複製貼上帶進了中文引號、欄位值該加引號沒加。修不動就把訂閱重新匯入一遍,讓服務商的原始設定覆蓋本地改動。
第三步:查連接埠
核心監聽的連接埠被別的程式占了,啟動直接失敗。查一下誰占著(連接埠號換成你設定裡的值):
# Windows
netstat -ano | findstr 7890
# macOS / Linux
lsof -i :7890
查到占用程序,要麼結束它,要麼給 Clash 換連接埠:改設定裡的 mixed-port 為一個空閒值,儲存重啟。
第四步:清殘留
上一次崩潰退出時,核心程序可能沒跟著死,占著連接埠和 TUN 虛擬網卡,新執行個體一啟動就撞車。手動清一次:
# Windows(程序名以工作管理員裡實際顯示為準)
taskkill /f /im mihomo*
# macOS / Linux
pkill -f mihomo
四步走完還不行,就走最後一條路:完全解除安裝後從下載中心重新安裝最新版,讓安裝程式把損壞的執行環境整個換掉。Windows 與 macOS 各自的高頻崩潰場景對照,部落格單獨寫了一篇:啟動崩潰閃退的日誌定位與修復步驟。
按平台補三條特有原因
- Windows:安全軟體把核心當成可疑程式隔離,是最高頻的原因之一——客戶端介面能開,點連線就退,日誌裡核心部分空空如也。到安全軟體的隔離區看有沒有被擋下的檔案,加信任後重新安裝。此外,把客戶端裝在中文路徑或含空格的深層目錄裡,個別版本會因為路徑解析失敗啟動不了,換到簡單的英文路徑試一次成本很低。
- macOS:從非商店管道下載的應用程式會被系統加上隔離標記,首次開啟需要在「隱私權與安全性」裡手動允許;跳過這一步的表現就是雙擊沒反應。TUN 或系統擴充功能相關的授權也必須在系統設定裡點通過,否則核心起來一半就退。
- Linux:多為權限與相依問題。TUN 模式需要相應的網路能力授權,直接以普通使用者啟動會在建立網卡時失敗;發行版缺少必要的執行庫時,終端裡會給出明確的缺庫提示,照著裝上即可。
崩潰之後怎麼留住證據
反覆崩潰卻抓不到原因的,把日誌級別調到 debug 再重現一次,然後從日誌末尾往上讀。真正有用的資訊通常在最後二三十行:解析到哪一行失敗、哪個連接埠繫結被拒、哪個檔案讀不到。想給開發者回饋或者自己留檔,記得同時保留三樣東西——客戶端版本號、核心版本號、以及觸發崩潰前做的最後一個操作。缺了這三樣,別人也幫不上忙。
如果崩潰只在匯入某一份特定設定後出現,那基本可以斷定是設定問題而不是客戶端問題。此時最快的辦法是二分法:把設定裡的 rules 段砍掉一半啟動一次,再砍一半,幾輪就能定位到具體那條規則或那個欄位,比逐行肉眼審查快得多。
C8 / 行動裝置專項
行動裝置專項:Android 和 iOS 各有各的脾氣
手機端的故障和桌面端不是一套邏輯:Android 的坑集中在授權與背景管控,iOS 的坑集中在系統 VPN 框架的狀態同步。分開說。
Android:三件事管住九成問題
- VpnService 授權。Android 端 Clash 靠系統的 VpnService 建本地通道,首次連線必彈「連線請求」授權視窗,必須點允許。誤點了拒絕,去系統設定的 VPN 頁面刪除該應用程式的 VPN 設定,回客戶端重連,授權視窗會重新彈出。
- 省電白名單。國產 ROM 的背景清理相當勇猛,核心程序被砍等於斷網,表現為「鎖螢幕幾分鐘後網路就沒了」。把客戶端加入省電白名單並允許自動啟動,是 Android 端的必做項。各主流廠商系統的設定路徑,部落格整理了一份:VpnService 授權與省電白名單。
- 分應用程式代理。只讓指定應用程式進通道,其餘應用程式直連。既省電,也能繞開個別應用程式與 VPN 通道的相容問題——某個應用程式一開代理就抽風,先把它踢出通道試試。
Android 安裝檔從下載中心 Android 區取,首選 Clash Plus。
iOS:狀態以系統設定為準
iOS 走系統的 Network Extension 框架,客戶端從 App Store 安裝,首推 Clash Plus。兩個高頻坑:
- 開關狀態不同步。應用程式內顯示已連線,狀態列卻沒有 VPN 圖示——以系統為準,去「設定 → VPN」裡手動撥開對應設定的開關。
- 舊設定殘留打架。裝過多個代理類應用程式的裝置,系統 VPN 列表裡會累積多份設定,互相搶接管權。把不再使用的設定刪乾淨,只留目前在用的一份。
行動裝置排查的三個通用動作
第一,先分清是「通道斷了」還是「解析壞了」。手機上沒有 curl 那麼方便,但可以用一個笨辦法:直接在瀏覽器裡造訪一個純 IP 的地址,如果 IP 能通、網域不通,問題就在 DNS 那一層,回 C5 處理;兩者都不通,才是通道本身的問題。
第二,善用流量統計。行動裝置客戶端一般都有即時上下行速率顯示。連線狀態正常但速率長期為零,說明流量根本沒進通道——十有八九是分應用程式代理把目標應用程式漏掉了,或者系統把客戶端的背景連網權限掐了。速率有跳動但網頁打不開,才需要往節點和規則上找。
第三,換網路交叉驗證。同一份設定,在 Wi-Fi 下正常、切到行動網路就不行,大概率是電信業者網路對某些連接埠或協定做了限制,換協定或換節點連接埠通常能解;反過來行動網路正常、Wi-Fi 不行,那要懷疑路由器上的 DNS 劫持或另一層代理,先去路由器設定裡看一眼。
行動裝置通用提醒
手機切換 Wi-Fi 與行動網路時,通道會重建,出現幾秒斷流屬正常現象;持續斷流才需要按本章排查。