適用於 v2rayN 切換伺服器後提示核心啟動失敗、更新後無法執行,或啟用路由規則便退出的情況。先分辨「程序未啟動」與「啟動後連線失敗」,再依據日誌末端的錯誤檢查監聽連接埠、設定欄位、可執行檔與規則資源。以下以 Windows 和 Xray 核心為主要範例;連接埠數字僅供排查參考,不代表每個安裝環境的預設值。
先分辨啟動失敗與連線失敗
v2rayN 是設定與管理介面,實際建立連線的是所選核心。主視窗能開啟,不代表核心已在執行;瀏覽器無法開啟網頁,也不代表核心啟動失敗。看到 timeout 就重新安裝用戶端,往往會錯過真正的故障原因。
| 日誌或現象 | 所屬階段 | 優先檢查項目 |
|---|---|---|
| 找不到指定檔案,未出現核心程序 | 建立程序之前 | 核心目錄、壓縮檔是否完整解壓縮,以及安全軟體的紀錄 |
failed to load config | 載入設定 | 後續錯誤提及的欄位、協定與規則檔名 |
failed to listen | 初始化本機監聽 | 監聽位址與連接埠占用情況 |
已有連線紀錄,接著出現 i/o timeout | 啟動後的連線階段 | 伺服器位址、網路、DNS 與傳輸參數 |
開啟主介面下方的日誌或資訊區域,保留一次啟動所產生的完整錯誤鏈。介面配置會因 Desktop 與 WPF 版本而異;重點是找到核心輸出,而不只是用戶端跳出的「啟動失敗」通知。錯誤鏈中的 > 常用來串連上下層原因,最後一段通常比開頭的概述更具體。
重現一次,固定排查條件
反覆切換伺服器、核心或路由設定,會讓日誌混在一起。先記下目前使用的核心、伺服器類型與本機監聽連接埠,再重現一次問題。以下路徑以常見的繁體中文介面為準;若選單配置不同,請依對應設定項目尋找,不要套用其他版本的目錄結構。
-
記錄原始設定
在主介面記下目前的伺服器與路由模式。前往「設定」→「參數設定」,記下本機監聽連接埠;再查看「Core 類型」相關設定,確認該協定實際選用的核心。
-
暫時清除系統代理
在系統匣選單的「系統代理」中選擇「清除系統代理」。這只會取消系統代理的指向,不會修復核心;但可避免排查期間其他應用程式持續連線至失效的本機連接埠。
-
保留單次測試日誌
先複製現有錯誤,再清空日誌顯示或記下時間。重新將伺服器設為作用中,觀察新一輪啟動輸出;不要同時更新訂閱並批次測試。
-
依錯誤修正
每次只修改一項。儲存後重新啟動核心,比較第一個具體錯誤是否改變;確認監聽恢復後,再恢復系統代理並測試實際請求。
連接埠占用:先查監聽程序
日誌出現 bind、listen tcp 或「通常每個通訊端位址只允許使用一次」時,先檢查本機連接埠。占用者可能是另一個 v2rayN 執行個體,也可能是上次關閉後殘留的核心程序。不同系統對同一錯誤的描述可能不同;判斷時應看監聽位址與連接埠,不必要求訊息逐字相同。
在 Windows 命令提示字元中執行以下查詢。數字必須替換成「設定」→「參數設定」中實際使用的連接埠。輸出中請留意本機位址欄、LISTENING 狀態與最後一欄的 PID;只有遠端位址包含該數字,並不能證明本機連接埠遭占用。
netstat -ano -p tcp | findstr ":10808"
netstat -ano -p tcp | findstr ":10809"
- 開啟「工作管理員」→「詳細資料」,依 PID 找到對應程式;必要時啟用 PID 欄並查看可執行檔位置。
- 若占用連接埠的是另一個用戶端執行個體,請先正常關閉該執行個體;不要對不明 PID 直接強制結束程序。
- 若該連接埠必須留給其他程式使用,請前往「設定」→「參數設定」修改本機監聽連接埠,儲存後重新啟動核心。
- 修改後,也要同步調整手動設定代理連接埠的瀏覽器或工具,再重新設定系統代理。別假設所有應用程式都會自動跟著變更。
設定欄位:沿著錯誤鏈找出具體原因
failed to load config 只是錯誤入口,還不足以判斷問題出在 JSON 格式、使用者識別資訊或協定相容性。一般伺服器的執行設定由介面產生,請優先回到伺服器編輯視窗修正;只有使用自訂設定時,才直接檢查對應的來源檔案。執行時產生的檔案可能在下次啟動時遭覆寫,不適合作為長期修正位置。
錯誤:invalid character
原因:解析設定時遇到無效字元,後續訊息通常會指出字元或所在位置。
解法:檢查自訂 JSON 是否包含中文引號、多餘的尾隨逗號或複製貼上的說明文字;不要只修改日誌中顯示的檔名。
錯誤:invalid UUID
原因:需要 UUID 的欄位無法依目前核心的要求解析,常見情況包括使用者識別資訊遭截斷,或誤貼了整條分享連結。
解法:在伺服器清單中編輯該設定,核對「使用者 ID」是否與伺服器提供的值相同,並移除前後空白;分享連結應從匯入入口加入,不要填入 ID 欄位。
錯誤:unknown config id
原因:目前的核心無法識別設定所引用的協定或設定類型,請搭配後續出現的名稱判斷。
解法:核對實際啟動的核心與設定來源。使用 REALITY 等功能時,請確認選用支援該功能的 Xray 核心;不要只修改協定名稱來繞過錯誤。
不同核心分支不能只憑相同的「VLESS」字樣判斷相容性。傳輸方式、安全層、flow 與其他參數也必須同時相符。若剛手動修改過這些欄位,請先還原訂閱提供的原始設定,再逐項確認伺服器端要求;將安全層改為不加密並不是通用的修復方式。
- 一般伺服器:在主介面編輯目前使用的伺服器,檢查位址、連接埠、使用者 ID、傳輸與 TLS 設定。
- 自訂設定:核對 JSON 語法與欄位層級;不能只因為欄位值「在另一種核心中可用」,就直接照搬。
- 訂閱產生的設定:先保留必要備份,再重新更新訂閱並確認能否重現問題;手動修改伺服器設定可能在下次更新時遭覆寫。
核心檔案:檢查路徑與架構
「系統找不到指定的檔案」若發生在建立程序時,通常尚未進入設定解析階段。此時反覆修改伺服器設定沒有幫助。先查看日誌指出的可執行檔路徑,再確認所選核心的檔案是否存在。不要把某個版本的 bin 目錄結構當成所有版本通用的規則。
| 現象 | 檢查位置 | 修正方式 |
|---|---|---|
| 路徑所指的檔案不存在 | 日誌中的核心路徑、解壓縮目的目錄 | 重新完整解壓縮對應的發行套件;若套件未包含核心,請使用用戶端提供的核心更新功能補齊 |
| 檔案出現後又消失 | Windows 安全性中心「病毒與威脅防護」→「保護歷程記錄」 | 確認封鎖原因與檔案來源,不要直接關閉整體防護 |
| 無法執行此應用程式 | 系統類型、程式套件架構 | 依實際架構重新選擇 x64 或 ARM64 等版本的套件 |
| 權限遭拒 | 檔案屬性、目錄存取權限、安全性原則 | 確認檔案允許執行且目錄可讀寫,不要將長期以系統管理員身分執行當成預設修復方式 |
不要直接在壓縮檔預覽視窗中執行主程式,也不要只取出主程式而遺漏其他目錄。排查前請先關閉用戶端、備份使用者設定,再將完整程式套件解壓縮至新的獨立目錄進行驗證。若新目錄能啟動、原目錄卻無法啟動,表示應繼續比對檔案與權限,而不是立刻覆蓋所有使用者資料。
規則檔案:分辨檔案缺失、標籤與路徑
只有啟用某種路由模式後才啟動失敗,且錯誤指向 geoip.dat、geosite.dat、geoip: 或 geosite: 時,應檢查規則資源。規則檔案用於提供 IP 或網域分類;若引用了不存在的分類標籤,也可能在載入設定時阻止啟動,不只是執行後無法比對流量。
錯誤:failed to open file
原因:核心讀取資源失敗;只有後續路徑指向規則檔案時,才屬於規則檔案問題。
解法:依照日誌中的路徑檢查檔案是否存在及能否讀取,再透過用戶端提供的 Geo 檔案更新功能補齊;不要以為將檔案隨意放在主程式旁就會生效。
錯誤:failed to load geosite
原因:無法載入網域分類資源,可能是檔案損毀,也可能是引用的標籤不存在於該資源中。
解法:繼續查看錯誤末端提及的檔名或分類名稱,並在「設定」→「路由設定」中檢查自訂規則的引用;更新相符資源後,再啟用該規則。
- 先備份目前的路由設定,再暫時停用最近新增且引用 Geo 分類的自訂規則,確認錯誤是否因此消失。
- 不要只切換成名稱不同、卻仍引用相同缺失資源的路由模式;請確認測試設定不再依賴出錯的資源。
- 外部規則檔案的路徑應以日誌和實際設定為準。透過命令列執行核心與由用戶端啟動核心時,資源搜尋環境可能不同。
- 資源恢復後,重新啟用原規則;除了確認核心能否啟動,也要確認目標流量是否使用預期的出站連線。
還原設定後的驗證與常見問題
修復完成的判斷依據不是日誌視窗「沒有紅字」,而是核心持續執行、預期連接埠正常監聽,且實際請求經過預期入口。先測試一個應用程式,再恢復其他依賴該代理的工具,避免同時引入多種代理設定。
出現 timeout,還需要繼續排查啟動失敗嗎?
先確認同一次啟動是否已成功監聽,以及是否有請求進入。若程序持續執行,且請求已進入出站階段,請改查伺服器連線狀態、DNS 與傳輸參數;不要再把執行期間的逾時當成檔案缺失處理。
換成其他連接埠後,瀏覽器還是無法開啟網頁?
先確認新連接埠的狀態是否為 LISTENING,再重新設定系統代理。若瀏覽器手動填入 127.0.0.1:10808,也要同步改成實際使用的連接埠;同時確認 HTTP 與 SOCKS 入口類型是否相符。
切換核心後就能啟動,代表原本的核心壞了嗎?
不能直接下結論。請比較兩個核心的實際檔案路徑、支援的傳輸功能與使用的規則資源。前往「設定」→「參數設定」核對 Core 類型相關選項,再檢查原核心日誌中指出的具體欄位。
重新安裝前應該保留哪些資料?
退出程式後,備份使用者設定、訂閱群組資訊、自訂路由與一份完整的失敗日誌。先在獨立目錄中驗證,再逐項還原設定;不要一次匯入所有舊設定,否則無法判斷是哪一項造成故障。