V2Ray 運行日誌怎麼看：常見錯誤訊息與定位方法

先確認日誌記錄的是哪個階段

V2Ray 或 Xray 的一次連線並不是單一動作。應用程式先將請求交給本機監聽連接埠，核心讀取路由規則，再解析目標網域、選擇出站連線、連接遠端伺服器，接著完成協定驗證與傳輸握手。日誌通常只記錄失敗所在的環節，不會直接提供完整的修復答案。排查時應將錯誤放回連線流程中理解，不要看到一行紅字就立即重新安裝用戶端。

最實用的讀法，是一起查看時間接近且屬於同一次操作的多筆記錄。先清除或暫停舊日誌，開啟一個明確的網址或啟動一個明確的應用程式，然後立即查看新出現的內容。這樣能避免把數小時前的訂閱更新錯誤、背景探測結果與目前的連線失敗混在一起。

日誌層級也要一併查看。info 常用於記錄正常啟動、接收連線與路由結果；warning 表示存在異常狀況，但不一定會導致所有連線失敗；error 才是目前任務明確失敗時的重點。某次連線報錯後，瀏覽器可能自動重試並成功，因此還要搭配網頁是否能開啟、節點測試是否通過，以及錯誤是否持續重複來判斷。

v2rayN 與 v2rayNG 在哪裡查看日誌

v2rayN：先看核心輸出，再看用戶端提示

v2rayN 的介面會因版本與版面設定略有差異。一般可在主視窗下方的日誌或資訊區域查看運行輸出；若該區域被摺疊，可從主介面的檢視、日誌或相關選單重新開啟。啟動節點、更新訂閱、測試延遲與切換系統代理時，用戶端提示與核心日誌可能出現在不同區域。排查連線問題時，應優先查看包含 Xray、V2Ray、inbound、outbound、transport 等字樣的核心運行記錄。

如果按下啟動後完全沒有新增日誌，先確認核心程序是否確實啟動。設定產生失敗、本機監聽連接埠被其他程式占用、檔案存取權限異常，都可能讓流程停在連線之前。此時反覆測速不會得到有效結論，應先處理啟動階段出現的第一個錯誤。

若日誌出現 accepted，並顯示來自本機位址的連線，表示瀏覽器或應用程式已將流量交給本機代理伺服器。之後才出現的 timeout、rejected 或握手失敗，通常應繼續檢查節點參數、網路路徑或遠端服務。相反地，如果瀏覽器持續報錯，但日誌中沒有對應的新連線，重點就在系統代理狀態、應用程式是否遵循系統代理，以及本機監聽連接埠是否與應用程式填寫的值一致。

v2rayNG：從側邊選單進入日誌頁面

v2rayNG 通常可從側邊選單進入日誌頁面。開始排查前先啟動設定，切回目標應用程式產生一次連線請求，再立即返回日誌頁面查看末尾內容。Android 系統的背景管理可能讓應用程式暫停或重建網路連線，因此也要確認 v2rayNG 的運行狀態仍然正常。

v2rayNG 使用 Xray 核心時，協定連線、DNS、路由與傳輸錯誤會由核心輸出。系統網路切換、虛擬網路介面狀態等資訊，可能與核心記錄交錯出現。判斷時仍採用相同原則：找出首次失敗的時間點，從最早出現的錯誤往後查看，不要只截取最後一行。

若 v2rayNG 日誌中能看到本機請求已進入，但每個節點都在相同階段逾時，先切換一次目前網路並重新測試；若只有一個節點失敗，而同一訂閱中的其他節點正常，則應優先核對該節點本身的參數或狀態。這種對照比單獨盯著一條錯誤訊息更有效。

rejected：請求在哪一端遭到拒絕

rejected 的字面意思是請求遭到拒絕，但拒絕者不一定是遠端伺服器。它可能來自本機路由規則、目標主機、代理協定驗證、傳輸層握手，或對端主動關閉連線。必須結合這一行前後的模組名稱與附加資訊判斷。

如果日誌同時出現 blocked、路由規則名稱或明確的阻斷出站連線，表示請求可能被本機規則送入阻斷出口。例如自訂規則將某個網域歸入拒絕清單，或規則順序導致目標在到達代理出站連線前就被匹配。此時應檢查目前路由模式，暫時將目標網域設為代理或直連進行對照，而不是更換 UUID。

如果出現 connection refused，通常表示到目標 IP 的網路連線已遭到明確拒絕。常見原因包括遠端連接埠沒有監聽、伺服器服務未啟動、連接埠填寫錯誤，或中間網路設備明確回傳拒絕。這與單純逾時不同：拒絕通常很快回傳，逾時則往往要等待數秒甚至更久。

當 rejected 與 handshake、authentication、invalid user 等資訊一同出現時，重點應轉向節點參數與伺服器端設定是否一致。逐項比對協定類型、伺服器連接埠、使用者識別碼、傳輸方式、安全設定、主機名稱與路徑。從訂閱匯入的節點不建議手動猜測並修改欄位；應先更新訂閱，再比較更新前後的設定。

也要留意目標網站本身的拒絕。節點連線與代理通道可能已正常，但特定目標回傳存取限制或主動中斷連線。判斷方法是使用同一節點造訪多個不同網站：如果大多數目標正常，只有一個目標持續失敗，就不應直接將問題歸因於 V2Ray 核心或節點驗證。

timeout：先確認逾時發生在哪個階段

timeout 是最常見也最廣泛的錯誤。它只表示某個步驟未能在規定時間內完成。DNS 查詢、TCP 建立連線、TLS 握手、WebSocket 連線、讀取回應都可能逾時。看到 timeout 後，先找同一行或上一層錯誤中的動詞，例如 lookup、dial、connect、handshake、read，這些詞能指出等待發生的位置。

連線至伺服器位址時逾時

如果記錄指向伺服器 IP 與連接埠，並出現 dial 或 connect，表示本機已嘗試建立外部連線，但未能及時完成。先測試同一訂閱中的其他節點，再切換目前網路測試。只有一個節點逾時，通常偏向該節點狀態或連接埠問題；所有節點在同一網路下逾時，但換網路後恢復，則較像目前的網路路徑問題；所有網路與所有節點都失敗，還要回頭檢查本機設定與核心啟動狀態。

握手階段逾時

底層連線建立後，協定與傳輸仍需要繼續交換資料。若日誌明確停在 TLS、WebSocket 或其他傳輸握手階段，需核對伺服器名稱、傳輸類型、路徑、主機欄位與安全參數。伺服器位址能連通，不代表上層參數一定相符。時間設定偏差也可能影響依賴憑證有效期或時間視窗的連線，因此桌上型電腦與 Android 裝置都應啟用準確的系統時間。

讀取資料時逾時

read timeout 或內容期限已到，可能表示連線已建立，但後續資料沒有回傳。若只在下載大型檔案或持續連線時發生，需要觀察網路穩定性；若每次開啟任意網頁都在相同秒數後失敗，則繼續檢查遠端服務、傳輸參數與 DNS 結果。不要只用延遲測試取代實際造訪測試，因為延遲探測與完整網頁連線可能採用不同的請求流程。

排查 timeout 的對照順序
1. 同一節點，換一個目標網站
2. 同一網路，換一個訂閱節點
3. 同一節點，切換目前網路
4. 更新訂閱後重新選擇節點
5. 對照日誌中的 dial、handshake、read 或 DNS 階段
6. 只修改一個變數，再進行下一次測試

invalid user：驗證資訊與伺服器端不一致

invalid user 通常出現在 VMess 等需要辨識使用者身分的協定處理過程中，表示伺服器端無法將收到的驗證資訊對應到有效使用者。最常見的原因是 UUID 不一致、節點設定已變更、仍在使用訂閱中的舊節點，或請求實際抵達了錯誤的伺服器連接埠。

第一步應更新訂閱，並確認目前選取的確實是更新後的節點。v2rayN 中可能同時保留舊群組、手動節點與新訂閱節點；名稱相近不代表參數相同。v2rayNG 也可能存在重複設定，因此要檢查目前的運行項目，而不只是確認訂閱更新提示是否成功。

如果節點是以手動設定建立，應逐字核對 UUID、協定與連接埠。UUID 多一個空格、少一個字元，或複製到錯誤欄位，都可能造成驗證失敗。不要將訂閱連結填入節點位址，也不要把節點分享內容拆開後憑經驗補填欄位。對於 VLESS，驗證與請求解析失敗時顯示的具體文字可能不同，但排查重點仍是使用者識別碼、流量控制、安全層、傳輸方式及伺服器端入口是否一致。

若多台裝置使用同一份剛更新的設定，只有一台持續出現 invalid user，可以先刪除該裝置上的舊節點並重新匯入訂閱，再確認沒有選取同名的舊項目。若所有裝置從同一時間開始失敗，且設定未經本機修改，則應請服務提供者檢查使用者狀態與伺服器端設定。

DNS 解析失敗：網域未轉換成可用位址

DNS 負責將網域名稱轉換為 IP 位址。日誌中的 failed to lookup、no such host、DNS query failed 或解析逾時，表示連線可能尚未抵達目標伺服器。這裡要先區分兩類網域：一類是節點伺服器位址，另一類是使用者正在造訪的目標網域。前者解析失敗會讓整個節點無法建立連線，後者失敗可能只影響特定網站。

節點伺服器使用網域名稱時，如果該網域解析失敗，日誌通常會在連線至遠端之前報錯。先檢查網域拼寫與目前網路是否能正常完成 DNS 查詢，再更新訂閱以排除位址已變更的可能。若伺服器直接填寫 IP，這一步不涉及伺服器網域解析，但目標網站仍需要 DNS。

只有部分網域失敗時，要檢查路由規則與 DNS 規則是否相互配合。例如網域被判定為代理，但 DNS 查詢被送往目前網路無法連線的解析器；或自訂規則回傳了不適合目前連線的結果。暫時切回用戶端預設的基本路由與 DNS 設定，可以判斷故障是否由自訂項目引起。

所有網域解析都逾時，但直接造訪已知 IP 仍有回應時，通常應將重點放在 DNS 伺服器可達性、系統網路與用戶端 DNS 設定。若日誌出現循環查詢或請求不斷重複，還應檢查本機監聽連接埠、系統 DNS 與代理 DNS 是否形成互相轉送。修改後需要重新啟動核心，讓舊連線與快取退出。

網域能解析不表示結果一定適合目前的鏈路。若解析出的位址無法連線，日誌可能先顯示解析成功，接著在 dial 階段逾時。此時錯誤已從 DNS 階段轉為網路連線階段，應依照 timeout 的方法繼續比較節點、網路與目標位址。

設定、連接埠與資源檔案錯誤

有些問題發生在核心啟動前，網頁自然不會產生任何代理連線。若日誌出現設定解析失敗、未知欄位、缺少必要參數或無法載入檔案，應先恢復可啟動的設定。手動編輯 JSON 時，逗號、括號、欄位層級與資料類型都必須符合格式；使用 v2rayN 或 v2rayNG 的訂閱匯入功能時，則應盡量在介面內完成修改，避免設定檔與用戶端產生的結果互相覆蓋。

address already in use 或類似的連接埠占用訊息，表示本機 SOCKS、HTTP 或其他入站連接埠已被另一個程序監聽。常見情況包括舊核心未退出、用戶端重複啟動，或其他本機服務使用相同連接埠。先完全退出目前的用戶端，再重新啟動；仍然報錯時，再調整用戶端的本機連接埠，並同步更新依賴該連接埠的應用程式設定。

路由資料檔案載入失敗時，依賴 geosite 或 geoip 的規則可能無法運作，嚴重時會阻止設定啟動。這類日誌通常會明確指出檔案不存在、無法讀取或規則名稱無效。應使用與目前用戶端及核心相配套的資源檔案，並檢查自訂規則引用的分類名稱是否存在。不要將資源檔案錯誤誤判為節點失效。

設定中出現未知欄位，也可能是用戶端與核心功能不相容。先使用下載中心提供的目前用戶端版本，並讓用戶端管理對應的核心。若要從舊設定遷移，建議先匯入訂閱產生一份基本設定，確認能夠連線後，再逐項加入路由或 DNS 自訂內容。

如何區分本機問題、節點問題與伺服器端問題

單筆日誌只能指出一個失敗現象，要定位問題歸屬需要搭配對照測試。最穩妥的方法是建立「節點、網路、裝置、目標」四個變數，每次只改變一個。這樣可以迅速縮小範圍，不會因為同時變更多個設定而失去判斷依據。

判斷本機問題時，重點查看核心能否啟動、請求能否進入本機入站，以及路由是否命中預期的出站連線。判斷節點問題時，重點查看同一用戶端中的其他節點是否正常。判斷伺服器端問題時，則需要多台裝置或網路得到一致結果，且日誌集中指向驗證、遠端連接埠或服務處理階段。

「延遲顯示正常但網頁打不開」並不矛盾。延遲測試可能只驗證某個連接埠可達，或完成一次較短的連線；實際網頁還要經過 DNS、路由、協定傳輸與目標存取。應以實際連線日誌為準，繼續尋找測試後出現的握手、讀取或目標連線錯誤。

一套可重複執行的日誌排查流程

1. 確認用戶端正在運行。查看 v2rayN 或 v2rayNG 的運行狀態，確保核心啟動後沒有立即退出。
2. 更新訂閱並選取明確節點。避免繼續使用同名舊節點，記錄目前節點名稱與更新時間。
3. 清除舊日誌。只保留一次新測試產生的內容，減少背景請求干擾。
4. 產生單一請求。開啟一個確定可存取的網站，不要同時執行測速、訂閱更新與大量下載。
5. 尋找第一個錯誤。從首次出現 error 或 warning 的位置向上查看數行，確認它屬於設定、入站、路由、DNS、連線還是驗證階段。
6. 依錯誤類型處理。rejected 檢查拒絕來源，timeout 檢查逾時動作，invalid user 檢查驗證資訊，DNS 錯誤檢查解析對象與解析器。
7. 每次只修改一個變數。先更換節點，再更換網路，或先恢復路由後重新測試，不要同時修改多個欄位。
8. 保存有用記錄。記錄時間、用戶端版本、核心類型、錯誤片段與已完成的對照測試，同時移除驗證資訊。

日誌排查的核心不是記住所有英文錯誤訊息，而是確認失敗發生在連線鏈路的哪個階段。只要能判斷請求是否進入本機代理、是否完成 DNS、是否連上伺服器、是否通過驗證，問題範圍就會從「完全連不上」縮小到一個可操作的檢查項目。

如果目前設定已經過多次手動修改，通常最省時間的做法是保留必要資訊，重新匯入訂閱，以基本路由完成一次連線，再逐項恢復自訂設定。v2rayN、v2rayNG 與 v2flyNG 都應遵循相同的變數控制方法：先建立可運作的基準，再定位是哪一項變更引入錯誤。