V2Ray 核心啟動失敗怎麼辦：從日誌找出 config.json 設定錯誤

先確認問題發生在啟動階段

核心啟動失敗與節點連線失敗不是同一類問題。啟動失敗時，V2Ray 或 Xray 程序通常會在讀取 config.json、建立入站監聽或初始化出站設定時退出；節點連線失敗則是核心仍在執行，但存取目標時發生逾時、握手失敗或伺服器拒絕。兩者的排查入口不同，不能只憑「網頁打不開」判斷。

開啟日誌後，先往上尋找本次啟動對應的第一則 error 或 failed。後續出現的「程序退出」「重新啟動失敗」通常只是結果，真正原因多半在前面一至五行。例如設定解析錯誤會先指出字元位置，接著才顯示核心退出碼；連接埠衝突則會先顯示監聽位址，再回報啟動失敗。

以 v2rayN 7.x 為例，可先進入「設定」→「參數設定」→「Core 類型」，確認目前節點呼叫的是 Xray Core 還是 v2fly Core，再回到主畫面開啟日誌區域。切換 Core 類型後應重新啟動一次，讓日誌只保留目前核心產生的新紀錄，避免把舊設定的錯誤誤認為目前問題。

1. 停止核心

   在用戶端執行停止操作，等待日誌出現程序結束訊息，確認舊程序不再占用本機監聽連接埠。

2. 清除日誌

   清除日誌視窗或記下目前時間，接著只啟動一次核心，避免連續重試產生大量重複錯誤。

3. 定位第一則錯誤

   從新日誌頂端往下尋找第一筆包含 failed、error、invalid 或 unknown 的紀錄。

4. 記錄上下文

   保留錯誤行前後各三行，重點記錄設定檔路徑、行列位置、監聽連接埠與出站標籤。

5. 逐項修改

   一次只修正一個問題，儲存後重新啟動。若同時修改多個欄位，新日誌很難判斷是哪項修改生效。

JSON 語法錯誤：依行列位置修正結構

config.json 必須符合標準 JSON 語法。鍵名與字串使用半形雙引號，陣列與物件分別使用方括號和大括號，相鄰欄位之間使用逗號，最後一個欄位後不可保留多餘逗號。中文輸入法產生的彎引號、遺漏的引號，以及複製時混入的註解，都會讓核心在處理協定參數前直接停止。

下面的片段在 port 行末缺少逗號，因此解析器讀到下一行的 protocol 時無法繼續。日誌提供的行號有時指向「發現問題的位置」，真正缺少的字元可能位於上一行。

{
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808
      "protocol": "socks"
    }
  ]
}

修正時不要只盯著錯誤字元本身。應從提示位置向上檢查最近一組大括號，確認每個物件中的鍵值對都有正確分隔，並從檔案開頭到結尾核對括號是否成對。若編輯器支援 JSON 格式化，可先執行格式化；無法格式化通常表示結構仍未閉合。

• 將中文引號替換為半形雙引號，尤其要檢查伺服器位址、UUID、標籤與協定名稱。
• 確認數字沒有寫成帶單位的字串，例如連接埠應寫成 10808，不能寫成 10808連接埠。
• 確認布林值使用小寫 true 或 false，不要寫成帶引號的文字。
• 儲存完整文字後再重新啟動核心，不要只在預覽視窗中修改尚未寫入磁碟的副本。

連接埠被占用：找出衝突程序與重複入站

JSON 能正常解析後，核心會依序建立入站監聽。若 v2rayN 的舊程序沒有退出、其他本機網路工具占用了相同連接埠，或 config.json 中兩個入站重複使用同一個位址與連接埠，啟動就會停在監聽階段。日誌中通常可看到 listen、bind、address already in use 等關鍵字。

常見測試設定會將 SOCKS 入站放在 127.0.0.1:10808，HTTP 入站放在 127.0.0.1:10809。這些數字並非所有用戶端版本的固定值，實際排查應以日誌和目前參數設定為準。如果日誌顯示衝突連接埠為 10808，就只檢查 10808，不必同時修改遠端伺服器連接埠。

在 Windows 上可於終端機執行以下命令，查看 10808 對應的程序編號。假設結果最後一欄顯示 6420，再透過第二個命令查詢程序名稱。看到連接埠被占用後，不要直接結束任意系統程序，應先確認它是否是尚未退出的舊核心執行個體。

netstat -ano | findstr :10808
tasklist /FI "PID eq 6420"

結論：先釋放連接埠，再考慮改號

舊程序殘留時直接改成 10810，只能暫時避開衝突，還會讓系統代理繼續指向舊連接埠。應先結束殘留執行個體並確認連接埠已釋放；只有在連接埠被必要程式長期使用時，才同步修改入站連接埠與系統代理設定。

欄位拼寫錯誤：區分層級、核心與設定格式

欄位名稱拼寫正確但層級放錯，同樣會導致設定載入失敗。以 TLS 的伺服器名稱為例，serverName 應位於對應的傳輸安全設定內，而不是隨意放在 outbound 根層。類似問題還包括把 settings 寫成 setting、把 streamSettings 寫成 streamSetting，或把陣列欄位寫成單一物件。

另一個常見來源是混用不同核心或不同版本的設定片段。v2rayN 可根據節點與 Core 類型產生設定，但 Xray Core 和 v2fly Core 對部分協定、流控值與傳輸欄位的支援範圍並不完全相同。設定在某個核心中可用，不代表原樣切換 Core 類型後仍能載入。

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": []
      },
      "streamSettings": {
        "security": "tls",
        "tlsSettings": {
          "serverName": "example.com"
        }
      }
    }
  ]
}

1. 確認 v2rayN「設定」→「參數設定」→「Core 類型」中選擇的核心與節點協定相符。
2. 檢查日誌顯示的實際設定路徑，避免編輯了備份檔案或舊目錄中的 config.json。
3. 將複雜設定縮減為一個入站、一個出站，確認能夠啟動後，再恢復 DNS、路由與其他入站。
4. 若錯誤來自訂閱節點，請在用戶端編輯節點參數後重新產生設定，不要只修改執行期間的暫存檔案。

結論：未知欄位不能靠移動位置反覆試錯

先確定目前 Core 類型與設定格式，再核對欄位所屬的物件。反覆將欄位移到不同層級，可能消除一則錯誤，卻產生語意錯誤，使核心啟動後仍無法建立連線。

協定參數缺漏：從入站到出站逐段檢查

JSON 語法與欄位層級都正確後，核心才會檢查協定參數。VMess 常見問題是使用者 ID 格式無效；VLESS 常見問題是位址、連接埠、使用者 ID、加密值或流控參數不相符；使用 TLS 時還要核對安全類型與伺服器名稱。參數缺漏不一定顯示為「missing」，也可能顯示為無法解析使用者、無效 UUID 或不支援的流控值。

匯入訂閱後出現這類錯誤，應先在用戶端開啟對應節點的編輯介面，確認伺服器位址前後沒有空格、連接埠介於 1 至 65535、使用者 ID 完整，且協定與傳輸類型沒有對錯位置。不要把訂閱位址本身當成節點伺服器位址，也不要將本機 10808 連接埠填入遠端伺服器連接埠欄位。

流程停在哪一段，決定檢查範圍。若日誌已顯示本機連接埠監聽成功，之後才回報找不到路由標籤，就不必回頭修改 SOCKS 入站；若在解析出站使用者時退出，表示 DNS 和路由尚未開始運作，應優先處理節點協定參數。

最小設定法：縮小錯誤範圍

當日誌同時出現多則設定錯誤時，最有效的方法不是一次修改所有欄位，而是建立可啟動的最小設定。先只保留一個本機入站和一個參數完整的出站，暫時移除自訂 DNS、路由規則、其他入站與複雜傳輸選項。核心能持續執行後，再按模組逐項恢復。

每恢復一個模組，都執行一次停止、啟動和本機連線測試。例如先恢復 DNS，確認沒有網域解析錯誤；再恢復 routing，確認規則引用的 inboundTag 與 outboundTag 都存在；最後恢復其他監聽。這樣能把「在幾十個欄位中找錯誤」縮小為「檢查剛加入的一個模組」。

1. 保留入站

   只保留一個監聽於 127.0.0.1 的本機入站，並使用目前未被占用的高位連接埠。

2. 保留出站

   僅保留一個參數完整的 VMess 或 VLESS 出站，刪除暫時不參與測試的備用節點。

3. 暫停路由

   暫時移除自訂 routing 規則，避免規則引用已刪除的標籤並干擾啟動判斷。

4. 啟動複測

   確認日誌不再出現設定錯誤，程序執行超過 3 秒，且本機監聽連接埠持續存在。

5. 逐項恢復

   按照 DNS、路由、其他入站、傳輸選項的順序恢復，每次只加入一個模組。

驗證啟動成功：日誌、連接埠與連線都要通過

設定不再報錯只是第一步。真正的啟動成功應同時符合三個條件：核心程序沒有立即退出、本機入站連接埠處於監聽狀態，以及用戶端發出的測試請求能經由對應出站。只看到「設定載入完成」但程序隨後退出，仍不能算恢復。

先觀察啟動後 3 至 10 秒的日誌。如果紀錄持續輸出執行資訊，且沒有新的 failed to start、panic 或退出碼，即可繼續檢查連接埠。在 Windows 上再次執行 netstat -ano | findstr :10808，應看到與目前核心程序對應的監聽紀錄；若用戶端實際設定為其他連接埠，請替換命令中的數字。

接著執行一次用戶端內建的延遲測試或連線測試。若此時出現 TLS 握手、伺服器逾時或連線遭拒，表示啟動問題已解決，故障已進入遠端連線階段。後續應檢查伺服器位址、網路可達性、TLS serverName、傳輸方式與節點有效性，而不是繼續修改 JSON 括號。

• 連續啟動兩次都能保持執行，排除偶發的舊程序殘留。
• 停止用戶端後本機監聽消失，再次啟動後監聽恢復。
• 日誌中不再出現設定檔行列錯誤、未知欄位或連接埠繫結失敗。
• 系統代理指向目前本機連接埠，而不是修改前的舊連接埠。
• 更新訂閱並重新產生設定後，修正結果仍然保留。

結論：分開驗收啟動成功與節點可用性

程序持續執行且本機連接埠正常監聽，表示 config.json 已通過啟動階段；之後出現的握手或逾時問題應轉入連線鏈路排查。分階段驗收可避免反覆修改已正確的設定結構。

若仍無法定位，可將本次啟動的第一則錯誤、前後三行日誌、目前 Core 類型、用戶端版本與發生問題的設定模組整理在一起。分享日誌前應移除伺服器位址、使用者 ID、訂閱位址等連線憑據，但保留錯誤類型、欄位名稱、行列位置與連接埠號碼；這些資訊才是判斷設定問題的關鍵。