v2rayN 核心啟動失敗怎麼辦：從日誌逐行找出設定錯誤

先確認失敗發生在哪個階段

v2rayN 是管理介面，真正負責建立入站、執行路由及連線至遠端伺服器的是 Xray 或 v2fly 核心。按下啟動後，用戶端會讀取節點與路由設定、產生執行設定，再呼叫所選核心。只要產生的設定無法解析、端口無法監聽或缺少必要欄位，核心就可能在一秒內退出。

「啟動失敗」和「啟動成功但無法連網」不能混在一起處理。前者通常看不到持續執行的 Core 程序，本機端口也沒有進入監聽狀態；後者則能看到類似「started」的啟動行，但造訪網站時出現連線逾時、網域名稱解析失敗或 TLS 交握錯誤。先釐清階段，就能避免反覆更換節點卻沒有找到真正的故障點。

1. 開啟日誌

   在 v2rayN 主視窗進入「說明」→「檢視日誌」；若目前版本直接顯示「資訊」區域，切換至該區域並清除舊紀錄。

2. 確認核心

   進入「設定」→「參數設定」→「Core 類型」，確認 VMess、VLESS 等節點實際分配給 Xray，不要讓已刪除或路徑失效的核心繼續被呼叫。

3. 重新觸發

   先停止服務，等待 3 秒後再啟動一次。只保留這次啟動產生的日誌，不要把訂閱更新紀錄和舊連線錯誤混在一起判斷。

4. 保存首次錯誤

   從底部往上找到最早出現的 error、failed、panic 或 fatal 行，連同前後各 5 行複製到文字檔中。

依時間順序讀懂核心日誌

核心日誌通常會依時間輸出。第一段是版本與啟動參數，第二段是設定讀取結果，第三段才是端口監聽與出站連線。排錯時應找出第一個導致流程中斷的錯誤，而不是只盯著最後一行「exited」或「stopped」。退出資訊只是結果，本身很少能說明根本原因。

2026/07/29 10:18:42 [Info] Xray 25.6.8 started
2026/07/29 10:18:42 [Info] loading config: config.json
2026/07/29 10:18:42 [Error] failed to listen TCP on 127.0.0.1:10809
2026/07/29 10:18:42 [Error] listen tcp 127.0.0.1:10809: bind: address already in use
2026/07/29 10:18:42 [Info] core exited with code 1

這段範例中真正有價值的是第四行。第一行表示 Xray 程序已被呼叫，第二行表示設定檔可以讀取，第三、四行將失敗定位到本機 10809 端口，最後一行只表示程序以非零狀態結束。因此此時不必修改伺服器位址、UUID 或傳輸方式，應先處理本機端口衝突。

如何處理端口占用與程序衝突

v2rayN 常見的本機端口包括 SOCKS 端口 10808 和 HTTP 端口 10809，但實際值應以「設定」→「參數設定」→「基本設定」中的本機監聽設定為準。如果另一個 v2rayN 執行個體、舊 Core 程序或其他網路程式已占用相同端口，新核心便無法建立入站監聽。

在 Windows 終端機中可以直接查詢端口對應的程序識別碼。下列命令只會讀取目前的監聽狀態，其中最後一欄是 PID。若命令沒有輸出，表示該端口目前沒有 TCP 程序監聽，應繼續檢查設定產生與權限問題。

netstat -ano | findstr :10808
netstat -ano | findstr :10809
tasklist | findstr 4320

• 若 PID 對應另一個 v2rayN 執行個體，請從工作列退出該執行個體，不要只關閉主視窗。
• 若 PID 對應舊的 Xray 或 v2fly 程序，先在目前的用戶端停止服務，再結束殘留程序。
• 若端口由必須執行的程式占用，請進入「設定」→「參數設定」修改 v2rayN 本機端口，並同步更新瀏覽器或其他應用程式中的手動代理端口。
• 修改後再次執行查詢命令，確認新端口由本次啟動的 Core 程序監聽。

JSON 格式錯誤與協定欄位缺漏

訂閱匯入的節點會被 v2rayN 轉換成 Core 可讀取的 JSON。手動編輯節點、匯入不完整的分享內容或修改自訂設定後，可能出現缺少逗號、括號未閉合、數字被寫成文字等問題。日誌通常會提供行號和欄號，應先定位語法位置，再檢查該位置前一個欄位。

{
  "address": "edge.example.net",
  "port": 443,
  "id": "00000000-1111-4222-8333-444444444444",
  "security": "auto",
  "network": "tcp"
}

上面是便於理解欄位類型的片段，不是可直接取代整份執行設定的檔案。端口應為數字，位址和 UUID 應為字串。若日誌指向某一行開頭，真正缺少的逗號往往位於上一行末尾。不要只刪除錯誤欄位，否則語法通過後仍可能因缺少協定必要項目而失敗。

如果只有一個節點啟動失敗，而同一群組中的其他節點能正常啟動，優先重新更新訂閱並檢查該節點欄位。如果所有節點都在同一行出現 JSON 錯誤，則更可能是全域路由、自訂 DNS 或範本設定損壞。兩者影響範圍不同，處理入口也不同。

位址解析、TLS 與 Core 類型錯誤

設定語法通過後，日誌可能開始出現 dial、lookup、certificate 或 handshake。此時 Core 通常已完成本機監聽，錯誤發生在遠端連線階段。判斷時可先查看錯誤對象是節點網域、本機 DNS 位址還是憑證名稱，不要把所有 timeout 都歸為同一種原因。

系統時間偏差也會影響憑證有效期判斷。校正時間、時區與自動同步狀態後重新連線，比直接修改憑證驗證選項更能保留問題範圍。若日誌明確指出憑證名稱與目標 SNI 不一致，應回到節點編輯視窗修正伺服器名稱。

2026/07/29 10:31:08 [Info] dialing tcp: edge.example.net:443
2026/07/29 10:31:08 [Error] tls: failed to verify certificate
2026/07/29 10:31:08 [Error] certificate is valid for node.example.net, not edge.example.net

這類紀錄已提供兩個網域。連線位址可以是 edge.example.net，但伺服器憑證對應 node.example.net 時，SNI 通常需要依節點設定填寫為憑證涵蓋的名稱。具體值必須來自有效訂閱或伺服器設定，不能只憑錯誤文字隨意猜測。

用最小設定復原並驗證結果

當日誌同時包含多類錯誤時，最穩妥的方法是縮小變數。保留一個來源明確的節點，暫時使用預設路由與預設 DNS，關閉目前不參與測試的自訂入站，再啟動 Core。最小設定可以分開驗證訂閱資料、全域規則與本機監聽。

1. 備份設定

   記錄目前的本機端口、Core 類型、DNS 與路由模式，並儲存關鍵日誌。不要依賴記憶來恢復複雜的分流規則。

2. 更新訂閱

   在「訂閱群組」中選取對應群組並執行更新，然後只選擇一個欄位完整且近期可用的節點進行測試。

3. 恢復預設值

   暫時停用自訂 JSON、額外入站和手動撰寫的 DNS 規則，保留預設本機監聽設定與基本路由。

4. 啟動核心

   清除日誌後啟動一次，等待 10 秒。確認日誌出現 started、監聽位址與端口，且後面沒有緊接著出現 fatal 或 exited code 1。

5. 逐項加回

   每次只恢復一項設定並重新啟動。哪一項加回後首次出現錯誤，故障範圍就落在該項設定中。

可用狀態至少應符合三項：Core 程序持續執行、本機代理端口保持監聽、發出請求時日誌出現正常的出站紀錄。如果只看到啟動成功卻沒有任何請求日誌，還要檢查系統代理是否已開啟，以及應用程式是否實際使用 v2rayN 提供的代理端口。