V2Ray 用戶端故障排查 依症狀分章定位

01 / 排查基準先固定變數,再逐層排除

故障排查最容易踩的坑,是同時改動多個設定項目。節點、協定、路由、DNS 一起換,即使連線恢復,也無法判斷是哪一項起了作用。本頁所有章節遵循同一條順序:先固定目前環境,把鏈路拆成若干段,從最靠近用戶端的一段開始驗證,確認一段通過之後再看下一段。

一條完整的代理鏈路可以拆成六段:應用程式發出請求、本機入站連接埠、本機核心行程、出站連線(協定與傳輸)、遠端伺服器、目標網站。每一段都有可以獨立驗證的檢查點,下表中把它們列在一起,後續章節的排查動作都圍繞這幾段展開。

開始之前先固定四項資訊

1. 用戶端與核心版本 — v2rayN 的日誌首行會列印核心名稱與版本。不同核心(V2Fly 與 Xray)對同一份設定的支援範圍不同,遇到欄位報錯先確認核心。
2. 本機入站連接埠 — 在設定裡記下 SOCKS 與 HTTP 連接埠分別是什麼,後面所有命令列驗證都要用到這兩個連接埠。
3. 目前出站參數 — 協定(VLESS、VMess、Trojan 等)、傳輸方式(tcp、ws、grpc)、是否開啟 TLS、SNI 或 Host 的取值。
4. 系統代理與 TUN 狀態 — 用戶端是否已經把代理寫進作業系統,或者是否以 TUN 模式接管全域流量。這兩種模式的處理方向完全不同。

同時準備一份排查筆記,記錄重現時間、當時的網路環境(Wi-Fi 還是有線、是否切換過網路)、改動過的設定項目。多數「時好時壞」的問題靠這份筆記就能找到規律,例如只在某個網路下出現、只在休眠喚醒後出現。

把日誌等級調高,重現一次

預設日誌等級通常只輸出警告,資訊量不夠。重現故障之前先把等級調到 info 或 debug,重現一次後立即調回,避免日誌檔持續膨脹。日誌每行都帶時間戳,和系統事件對照時可以精確到秒。日誌的結構與常見報錯的讀法,在《v2rayN 執行日誌怎麼看》裡有完整拆解。

用命令列單獨執行核心

用戶端介面的日誌面板本質上就是核心行程的標準輸出。把設定匯出成 config.json 之後,可以在命令列手動執行一次,排除介面層的干擾:

# Xray 核心:只驗證設定,不啟動服務
xray run -test -config config.json

# Xray 核心:前景啟動,日誌直接列印到終端機
xray run -config config.json

V2Fly 核心把指令換成 v2ray test -config config.json 與 v2ray run -config config.json 即可,參數含義一致。

最後一條判斷原則:如果同一訂閱裡的多個節點同時逾時,優先懷疑本機網路、訂閱本身或用戶端設定;如果只有個別節點逾時,優先懷疑節點所在的伺服器與線路。這條原則決定了後面該往第 03 章還是第 04 章走。

02 / 症狀一顯示已連線,網頁打不開

用戶端裡的「已連線」只說明本機核心行程啟動成功、入站連接埠開始監聽,不代表資料能穿過出站到達目標網站。這個症狀涵蓋的範圍最廣,依下面四步可以把問題定位到具體一段。

第一步:確認本機連接埠在監聽

# macOS / Linux
lsof -nP -iTCP:10808 -sTCP:LISTEN

# Windows
netstat -ano | findstr "10808"

沒有任何輸出,說明入站沒有起來。檢查用戶端行程是否真的在執行、設定裡的入站連接埠是否被其他程式佔用,處理方式見第 07 章。

第二步:用 curl 繞過瀏覽器直接測試代理

curl -x socks5h://127.0.0.1:10808 -I https://www.example.com
curl -x http://127.0.0.1:10809 -I https://www.example.com

兩條指令分別測試 SOCKS 與 HTTP 兩個入站。結果對照:

• 兩條都回傳回應標頭:代理鏈路正常,問題在瀏覽器或系統代理層,轉第 07 章。
• 兩條都不通:出站或遠端有問題,轉第 03 章。
• 只有一條通:對應連接埠的入站設定或協定類型有問題,檢查設定裡兩個入站是否都啟用。

socks5h 裡的 h 表示網域交給代理解析;不加 h 則由本機先解析成 IP 再交給代理。測試時用 socks5h 可以排除本機 DNS 的干擾,兩者的差異在第 06 章展開。

第三步:檢查路由規則是否把目標走了直連

用戶端常見的分流預設裡通常包含「依網域區域分流」的規則。如果目標網域被判為直連,而直連線路本身不通,瀏覽器表現和「代理沒生效」完全一樣。定位方式是把日誌等級調到 info,存取目標網站,看日誌裡對應請求的出站標籤是直連還是代理。

如果確認是誤判,有兩種處理方式:在路由設定裡把該網域加入代理規則;或者暫時把預設出站改成代理,驗證是否規則導致。一份可參考的規則骨架:

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      { "type": "field", "domain": ["geosite:cn"], "outboundTag": "direct" },
      { "type": "field", "domain": ["geosite:geolocation-!cn"], "outboundTag": "proxy" }
    ]
  }
}

規則的比對順序是從上到下,先命中的生效,所以更具體的項目要寫在前面。這個話題在《路由規則設定實戰》裡有更完整的展開。

第四步:對照直連,排除目標網站自身問題

用不經過代理的網路存取同一網站。如果直連也打不開,問題不在用戶端,不必繼續改設定。這一步看起來簡單,卻能擋掉相當一部分「排查了半天發現是對方網站故障」的情況。

03 / 症狀二節點逾時與握手失敗

這一類問題的共同點是本機核心已經運作,但資料出不去。日誌裡會出現明確的錯誤行,先依關鍵字分類,再決定往哪個方向查,比逐項改設定快得多。

日誌關鍵字對照

先做連通性測試,再懷疑設定

# Linux / macOS:測試 TCP 連接埠能否建立連線
nc -vz 203.0.113.10 443

# Windows PowerShell
Test-NetConnection -ComputerName 203.0.113.10 -Port 443

範例裡的位址來自文件專用位址段,實際使用時替換成自己節點的伺服器位址與連接埠。結果判斷:

• 連接埠不通:伺服器沒有監聽、伺服器端防火牆攔截,或者線路層面不可達。先確認伺服器端狀態,再考慮換連接埠或換線路。
• 連接埠通、用戶端仍回報逾時:檢查用戶端裡填寫的位址是網域還是 IP。如果是網域,可能是解析環節出了問題,轉第 06 章。
• ICMP ping 不通不代表連接埠不通。多數伺服器預設不回應 ping,以 TCP 測試結果為準。

認證參數與時間偏差

VMess 協定會用時間戳參與認證,用戶端與伺服器的時間偏差超過允許範圍時會被直接拒絕。檢查系統時間是否開啟自動同步;虛擬機與雙系統裝置在長時間休眠之後時間漂移是常見來源。UUID、密碼一類的憑證欄位區分大小寫,複製時容易漏掉尾端字元。

TLS 與傳輸參數

• 開啟 TLS 的節點,SNI 必須與伺服器端憑證相符,填錯會得到握手失敗。
• REALITY 節點需要正確的 serverName 與公鑰(publicKey),兩者缺一不可。這兩個參數的原理見《REALITY 與 XTLS Vision 科普》。
• 傳輸方式為 ws 或 grpc 時,path 與 host 必須與伺服器端一致,並且區分大小寫。
• 傳輸層的 host 欄位和 TLS 的 SNI 是兩個不同的參數,不要互相混填。

如果多個節點同時出現逾時,而且連通性測試都失敗,把懷疑重點從單一節點移到本機網路出口或訂閱本身;如果只有某個節點在固定時間段逾時,記錄時間規律後聯絡服務提供方核對。

04 / 症狀三訂閱更新失敗與節點清單異常

訂閱是節點清單的來源。更新失敗會表現為節點全部消失、清單停留在舊內容,或者更新按鈕轉圈之後彈出錯誤提示。先確認訂閱內容本身能不能取得,再看用戶端側,順序不要顛倒。

第一步:在命令列直接拉一次訂閱

curl -L -A "v2rayN" -o sub.txt "https://example.com/api/v1/client/subscribe?token=xxxx"
head -c 300 sub.txt

第一條指令把訂閱內容儲存到檔案,第二條列印前 300 個字元用於判斷回傳形態:

• 回傳一段 base64 字串:這是正常的節點清單編碼,問題在用戶端側。
• 回傳 HTML 頁面:訂閱位址失效,或者請求被中間層攔截後跳轉到了錯誤頁。
• 回傳 404 或 403:位址已過期、token 錯誤,或者伺服器端限制了 User-Agent。範例裡的 -A "v2rayN" 就是指定 User-Agent,部分伺服器端會依它區分請求來源。

需要先有節點才能更新訂閱

如果訂閱伺服器只在代理可達的網路裡,而用戶端此刻沒有任何可用節點,就會陷入「沒有節點 → 更新不了訂閱 → 更沒有節點」的循環。處理方式有兩種:在訂閱設定裡啟用「透過代理更新訂閱」,並先手動匯入一個可用節點;或者先在能直連訂閱伺服器的網路環境下完成一次更新,節點匯入後再切換網路。

更新之後節點變少或消失

• 分組過濾:檢查是否設定了依名稱或地區篩選的分組,被過濾掉的節點不會顯示。
• 覆寫:部分用戶端的訂閱更新會整體替換該分組的內容,手動加入的節點要放在獨立分組裡,避免被覆寫。
• 去重合併:同一伺服器的多條線路在匯入後被合併成一條,數量減少屬於正常現象。
• 伺服器端調整:訂閱內容本身發生了變化,以最新一次拉取的結果為準。

自動更新與手動更新的差異

設定裡的更新間隔決定自動更新的頻率。手動更新通常有兩個入口:完整更新會重新拉取並覆寫節點清單;只重新整理訂閱內容的方式不會修改目前選取的節點,適合在連線穩定時保持現狀。排查期間建議先關閉自動更新,避免背景工作干擾判斷。

05 / 症狀四能連上但速度慢、頻繁斷線

「慢」至少有四種不同的表現:握手慢(開啟頁面之前的等待長)、頻寬低(下載速度上不去)、抖動(時快時慢)、斷線(連線中斷)。四種表現的處理方向不一樣,先對號入座再動手。

另外要區分三種常見延遲數值:ping 測的是 ICMP 往返,真連線延遲測是代理鏈路建立時間,下載測速測的是實際吞吐。三者測量對象不同,不能互相替代。《延遲測試三種數值對比》裡給出了每種數值的適用情境與常見誤讀。

先做直連對照

用同一台裝置、同一時間段,不經過代理存取一個同區域的大檔案下載位址,記錄速度。直連本身就不穩定的話,問題在本機網路或電信業者出口,繼續調用戶端沒有意義。

確認流量確實走了代理

日誌裡查看目標網域的出站標籤。速度慢有時是因為規則把目標走了直連,而直連線路恰好壅塞,看起來像是「代理很慢」。

傳輸方式與多工

• 多工(mux):把多條連線合併到一條 TCP 上,在低丟包線路上可以減少握手開銷;在高丟包線路上,一條連線出問題會拖慢所有多工在上面的請求。可以開關對照測試。
• 傳輸方式:tcp 最直接;ws 與 grpc 在特定網路環境下更穩定,但多一層封裝會帶來額外開銷。
• 加密演算法:不同演算法在效能較弱的裝置上吞吐差異明顯,可以嘗試更換後對比。

MTU 與分片

大封包在鏈路上被丟棄時,典型表現是「網頁能開啟,下載卡住」或者「影片緩衝時間長」。可以在用戶端或系統層面逐級調小 MTU,每次減 8 到 16 位元組,觀察是否改善。調整後要重新連線一次才會生效。

斷線的常見來源

• 伺服器負載變化或線路切換;
• 本機網路切換:Wi-Fi 與有線之間切換、行動網路切換基地台;
• 系統休眠喚醒後代理行程狀態異常,需要重連一次;
• 長時間閒置連線被中間設備清理,重連後恢復。

06 / 症狀五部分網域解析異常

這類問題的典型表現是:大部分網站存取正常,個別網域打不開;或者解析到的 IP 與實際不符;或者存取某個區域內的網站時延遲明顯偏高。共同點是問題出在「網域變成 IP」這一步。

網域在哪裡被解析

使用 SOCKS 代理時,網域解析的位置取決於用戶端設定:

• socks5h(帶 h)或開啟網域嗅探:網域交給核心依 DNS 設定解析;
• socks5(不帶 h):本機先解析成 IP 再交給代理,本機 DNS 的問題會直接被帶進代理鏈路。

排查時先用 socks5h 測試一次,可以快速區分「本機 DNS 問題」和「代理鏈路問題」。

調整用戶端的 DNS 設定

{
  "dns": {
    "servers": [
      { "address": "1.1.1.1", "domains": ["geosite:geolocation-!cn"] },
      { "address": "223.5.5.5", "domains": ["geosite:cn"] }
    ]
  }
}

這段設定讓不同區域的網域走不同的 DNS 伺服器,減少跨區域解析帶來的額外延遲。改完要重啟核心行程才會生效。

路由規則需要網域資訊才能比對

以網域為基礎的路由規則要先拿到網域。如果流量以 IP 形式進入核心,網域規則無法比對,請求會落到預設出站。開啟網域嗅探(sniffing)之後,核心可以從 HTTP 請求與 TLS 握手的資訊裡還原網域:

{
  "inbounds": [
    {
      "tag": "socks-in",
      "port": 10808,
      "listen": "127.0.0.1",
      "protocol": "socks",
      "sniffing": { "enabled": true, "destOverride": ["http", "tls"] },
      "settings": { "udp": true }
    }
  ]
}

開啟嗅探之後,網域規則與網域分流才會依預期運作。如果發現規則「明明寫了卻不生效」,先確認嗅探是否開啟。

單一網域的定向修正

如果只有個別網域解析異常,可以在 hosts 設定裡寫死正確位址,或者在 DNS 設定裡為該網域單獨指定伺服器。改動範圍越小,越容易驗證效果,也越不容易引入新的問題。

重新整理系統 DNS 快取

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux(systemd-resolved)
sudo resolvectl flush-caches

07 / 症狀六系統代理不生效與連接埠佔用

典型表現是:用戶端顯示已連線,瀏覽器打不開網頁,但命令列 curl 走本機代理是通的。這說明代理鏈路本身沒問題,問題出在系統代理沒有寫進去、寫錯了位置,或者連接埠對不上。

各平台系統代理的檢查位置

系統代理寫不進去的常見原因

• 用戶端權限不足,無法修改系統代理設定;
• 其他代理類軟體正在執行,搶佔同一項設定;
• 瀏覽器使用獨立的代理設定或代理擴充功能,忽略系統設定;
• 系統代理只影響讀取系統設定的應用程式,部分應用程式需要 TUN 模式才能接管。

TUN 模式與系統代理的差異

連接埠佔用

# Windows:查出佔用連接埠的行程號
netstat -ano | findstr ":10808"
tasklist | findstr "<PID>"

# macOS / Linux
lsof -nP -iTCP:10808 -sTCP:LISTEN

找到佔用行程之後,結束它,或者把用戶端入站連接埠改成其他未被佔用的連接埠。

改完連接埠後的完整動作

1. 在用戶端設定裡修改入站連接埠並儲存;
2. 關閉再重新開啟「系統代理」開關,讓新連接埠寫入系統;
3. 在系統設定裡核對代理位址與連接埠是否一致;
4. 用 curl 走新連接埠驗證一次,確認鏈路暢通。

08 / 症狀七用戶端啟動失敗與設定損毀

表現為雙擊無反應、啟動後立刻結束、介面正常但核心反覆重啟。先分清是「用戶端介面起不來」還是「核心行程起不來」,兩者的排查方向不同。

先驗證設定語法

# Xray 核心:只驗證設定,不啟動服務
xray run -test -config config.json

# V2Fly 核心
v2ray test -config config.json

常見報錯與含義:

• invalid character:JSON 裡有非法字元,常見來源是多餘逗號、註解、中文引號;
• unexpected end of JSON input:括號或引號沒有閉合;
• unknown field:欄位名稱拼錯,或者目前核心不支援該欄位。

設定裡出現註解與尾隨逗號都會導致解析失敗,從其他地方複製設定片段時最容易帶進這類問題。

核心反覆重啟

介面顯示執行中,但日誌裡核心行程反覆啟動又結束,通常是設定驗證失敗,或者連接埠被佔用。先把日誌等級調到 debug,看每次結束前的最後一行,再依第 03 章與第 07 章的流程處理。

權限與路徑

• 安裝目錄位於系統保護目錄下時,寫設定需要管理員權限,可以把資料目錄改到使用者目錄;
• 路徑中包含特殊字元或層級過長時,個別系統元件會讀取失敗;
• 移動過設定檔位置之後,用戶端記錄的舊路徑會失效。

安全軟體攔截

部分安全軟體會把代理核心判定為風險程式並靜默攔截。典型表現是行程啟動幾秒後消失,而命令列手動執行同一份設定正常。處理方式是在安全軟體裡為該目錄加入例外,或換一個安裝目錄重試。Windows 上首次安裝的流程與常見坑位,在《Windows 安裝 v2rayN 全流程》裡有分步說明。

設定備份與還原

改動設定之前先匯出一次。出現啟動問題時用重設功能回到預設設定,再逐項還原,可以定位到具體是哪一個設定項目導致的問題。手動匯入節點比重放整個設定目錄更安全,也更容易回復。

09 / 症狀八Android 端專項排查

Android 上執行的是 v2rayNG(Xray 核心)與 v2flyNG(v2fly 核心)。兩者的運作方式與桌面端不同:手機端以 VPN 模式接管流量,不存在「系統代理」這一層,所以桌面端的一部分排查項目在手機上不適用,反過來也一樣。

兩款用戶端的差異

同一份分享連結在兩者上都能匯入,但個 較新的協定參數只在 Xray 核心上生效。遇到「能匯入但連不上」的情況,換另一款用戶端對照一次,可以快速判斷是參數問題還是用戶端問題。兩款用戶端的安裝包入口都在下載頁的 Android 區。

連不上的常見原因

• VPN 授權彈窗沒有確認:首次連線時系統會彈出授權對話框,必須允許建立 VPN 連線;
• 系統中已有其他 VPN 類應用程式在執行:同一時間只允許一個 VPN 通道;
• 省電策略:應用程式在背景被系統清理,表現為通知列圖示消失、連線中斷;
• 分應用程式代理:只勾選了部分應用程式,未勾選的應用程式不經過代理。

訂閱與節點管理

手機上更新訂閱失敗時,先切換網路再試:行動數據與 Wi-Fi 互換一次。更新後節點順序變化屬於正常現象,以訂閱內容為準。訂閱位址帶 token,不要把截圖發到公開場合。節點清單的整理方式與桌面端一致,訂閱更新失敗的判斷流程可以直接沿用第 04 章。

日誌與自我檢查

v2rayNG 的日誌頁可以看到核心輸出,排查方式與桌面端一致:先看時間戳對應的錯誤行,再區分逾時、認證還是 DNS 問題。手機端沒有命令列環境,驗證手段以換節點對照、切換網路對照為主。

如果上面九章都沒有涵蓋到你的情況,可以把現象整理成一句話:什麼操作、什麼時間、日誌裡最後一行是什麼。常見問題頁依主題收錄了更細的問答,名詞解釋頁可以用來核對日誌裡的術語含義。