核心啟動失敗時，先分辨是設定解析失敗、本機監聽失敗，還是啟動後的網路連線問題。本文適合遇到 v2rayN 核心退出、v2rayNG 服務啟動異常的使用者：從單次啟動的日誌著手，依序檢查 JSON、協定欄位、監聽連接埠和規則資料檔，最後透過本機監聽與實際請求確認是否修復。
一、先分辨：核心未啟動，還是請求無法連線
v2rayN 是用戶端介面，Xray、V2Fly 等核心則負責讀取設定、建立入站監聽並執行出站連線。介面能開啟、訂閱能更新，不代表核心已成功執行。反過來說，瀏覽器無法開啟網頁，也不一定是核心啟動失敗：遠端連線逾時、憑證驗證失敗和 DNS 查詢異常，都可能發生在核心啟動之後。
這個流程用來判斷錯誤階段，不代表所有核心版本都嚴格依照此內部呼叫順序。排查時先找出啟動失敗日誌中最深層的具體原因；如果核心已持續執行，之後才出現 connection refused 或 i/o timeout，應依目標位址判斷是本機接入問題還是遠端連線問題，不能直接歸類為 JSON 錯誤。
- 設定階段：出現解析錯誤、無法辨識協定或讀取規則資料失敗，通常應先修正設定或資源路徑。
- 監聽階段：出現
bind、listen tcp等關鍵字時，優先檢查本機位址、連接埠占用情形和權限。 - 請求階段：已有入站接收紀錄，之後才出現遠端逾時，應檢查節點、DNS、路由和伺服器連線狀態。
二、收集一次完整的啟動日誌
日誌應從按下啟動前開始記錄，直到錯誤出現後為止。不要只截取「啟動失敗」四個字；介面上的提示通常只是結果，真正原因往往藏在後續的 failed to、檔名或系統錯誤訊息中。連續重複啟動會混淆多次執行的資訊，請先停止服務，再單獨重現一次。
-
記錄環境
記下作業系統、用戶端版本、目前核心名稱與核心版本。v2rayNG 使用 Xray，v2flyNG 使用 V2Fly；v2rayN 則應以目前選用的核心為準，不要從視窗名稱推測。
-
開啟日誌
在 v2rayN 主視窗底部查看日誌區域；若面板已收合，請先展開。v2rayNG 可從主畫面選單進入「日誌」。不同版本的入口位置可能不同，請以目前介面標示為準。
-
單次重現
先停止連線並記下目前時間，再啟動一次。保留啟動前後連續的紀錄，尤其要完整保存第一則失敗提示及其原因脈絡，不要只留最後一行。
-
先備份再修改
先備份自訂設定和路由規則，每次只修改一個項目。分享日誌前，請隱去訂閱網址、節點憑證、UUID、伺服器位址及個人目錄名稱，但保留欄位名稱、錯誤類型和連接埠。
若用戶端提示無法建立核心程序，而且完全沒有核心輸出，請先檢查核心執行檔是否存在、壓縮檔是否完整解壓縮、系統安全性紀錄是否封鎖執行，以及安裝套件是否符合處理器架構。這類問題發生在解析設定之前，反覆修改節點參數通常無濟於事。
三、連接埠遭占用：先找出監聽程序，再更換連接埠
本機代理需要在指定的監聽位址與連接埠上建立監聽。同一位址上的同一個 TCP 連接埠，通常不能同時由兩個獨立的監聽器占用。重複開啟用戶端、舊核心程序未結束，或其他程式使用相同連接埠，都可能讓新核心立即退出。請勿混淆遠端伺服器連接埠與本機入站連接埠。
錯誤：bind: address already in use
原因：目標監聽位址與連接埠已遭占用。解法：查出占用的程序，正常關閉重複執行的實例；若確實需要同時執行，請為兩個程式設定不同的本機監聽連接埠。
錯誤：Only one usage of each socket address (protocol/network address/port) is normally permitted.
原因：Windows 拒絕重複繫結通訊端位址。解法：從日誌確認具體連接埠，再透過監聽清單找出對應程序；不要直接結束名稱不明的系統程序。
以上數值僅供排查示範，並非所有版本的預設值。假設日誌顯示 127.0.0.1:10808 繫結失敗，請在 Windows PowerShell 執行下列指令，取得占用該連接埠的程序 ID，再查詢程序名稱。
Get-NetTCPConnection -State Listen -LocalPort 10808 |
Select-Object LocalAddress, LocalPort, OwningProcess
Get-Process -Id (Get-NetTCPConnection -State Listen -LocalPort 10808).OwningProcessLinux 可執行 ss -ltnp 'sport = :10808'，macOS 可執行 lsof -nP -iTCP:10808 -sTCP:LISTEN。查無結果只代表查詢當下沒有符合條件的 TCP 監聽，不能排除啟動瞬間發生衝突、UDP 衝突或權限限制；應配合日誌中的網路類型判斷。
- 發現舊核心程序時，先透過所屬用戶端正常退出，確認連接埠已釋放，再啟動目標用戶端。
- 改用
10818前，也要確認該連接埠未被占用；修改後，別忘了同步更新手動設定的瀏覽器代理、終端機代理或其他本機接入設定。 - 如果日誌指出本機 IP 不存在，請修正監聽位址。若只供本機存取，可依需求使用
127.0.0.1；不要只為了消除錯誤而任意開放所有網路介面。
四、JSON 語法錯誤：分辨「格式有誤」與「欄位不相容」
嚴格 JSON 規定鍵名和字串必須使用英文雙引號，陣列與物件中的逗號位置也必須正確。使用中文引號、最後一個欄位後多出逗號，或複製時漏掉括號，都會使設定在讀取階段失敗。部分載入方式支援註解等擴充語法，其他方式則未必支援；為減少差異，排查時請先使用嚴格 JSON 格式的副本。
錯誤：invalid character '}' looking for beginning of object key string
原因：物件結構不符合解析器要求，常見情況是最後一個欄位後多了逗號。解法：檢查錯誤位置附近及前一行，刪除多餘逗號並確認括號配對正確。
錯誤：unexpected EOF
原因：物件、陣列或字串尚未結束，輸入內容就已提前結束。解法：確認檔案是否複製完整、下載是否中斷，再補齊缺少的結構；不要只在檔案末尾盲目加上括號。
以下片段僅用來說明語法，並非可直接執行的完整代理設定。loglevel 後沒有多餘逗號，外層與內層物件也各自完整閉合：
{
"log": {
"loglevel": "warning"
}
}JSON 通過格式檢查，只能證明文字結構合法，不能證明協定名稱、傳輸設定和欄位類型都正確。部分無法辨識的欄位也可能遭到忽略，而不會觸發啟動錯誤。因此，仍須使用目前實際運行的核心測試設定。
.\xray.exe run -test -config .\config.json- 上例適用於提供該指令的 Xray 版本；請先執行
.\xray.exe help run確認參數。Linux、macOS 請改用對應的執行檔路徑。 config.json必須是本機實際存在的設定副本。若用戶端會自動產生設定，請確認測試的內容正是目前節點執行時使用的設定。- 命令列測試與用戶端啟動時，可能使用不同的工作目錄、環境變數和資源路徑。即使測試通過，仍須回到用戶端重新確認。
- 不要將含有節點憑證的完整 JSON 上傳至不熟悉的線上格式化服務。請優先使用本機編輯器與核心測試功能。
五、未知協定與欄位錯誤：確認實際執行的核心
分享連結、訂閱內容和原生設定是不同類型的輸入。vless:// 或 vmess:// 分享連結必須由用戶端解析，不能直接存成 JSON 設定交給核心讀取。訂閱中的節點出現在清單裡，也不代表目前的核心支援其所有傳輸和安全參數。
錯誤：unknown outbound protocol
原因：出站協定名稱拼錯，或目前的核心不支援該協定。解法：檢查 outbounds 中的 protocol，確認核心名稱與版本，再修正設定或改用相容的核心。
錯誤：json: cannot unmarshal string into Go value of type uint32
原因：原本應為數值的欄位被寫成字串；具體目標類型和錯誤訊息會因核心實作而異。解法：依日誌指出的欄位確認類型，例如數值型連接埠應寫成 443，而不是 "443"。
VLESS 是協定名稱，REALITY 則是相關安全設定的一部分，兩者不能互相替代作為 protocol 的值。傳輸方式、安全設定、伺服器名稱與憑證都應符合伺服器要求；只把協定名稱改成能啟動的值，不代表節點就能連線。
- v2rayN：確認目前節點使用的核心及其啟動日誌。更換核心後，請重新產生設定，避免繼續測試先前留下的設定檔。
- v2rayNG：以用戶端隨附的 Xray 功能為準。若無法辨識新參數，請先確認用戶端和核心版本，再判斷是否需要更新。
- v2flyNG：依照 V2Fly 的設定規範處理。不要假設將 Xray 專用的完整 JSON 原樣匯入，就能得到相同效果。
六、geo 檔案遺失：檢查資料名稱、路徑與規則引用
路由中的 geosite: 和 geoip: 引用需要相應資料支援。即使設定本身語法正確，執行環境若找不到資料檔，或資料中不存在引用的分類，也可能導致規則建立失敗。先確認錯誤是「無法開啟檔案」還是「找不到分類」，兩者的修復方式不同。
錯誤：failed to load geosite
原因：無法載入網域規則資料，可能是檔案遺失、路徑錯誤、檔案損毀或分類不存在。解法：查看後續錯誤原因，確認目前核心實際使用的資源目錄與規則分類。
錯誤：no such file or directory
原因：日誌指出的路徑不存在；只有錯誤同時指向 geo 資料檔時，才能判定是這類資源問題。解法：檢查完整檔案路徑、檔名大小寫及解壓縮後的目錄結構，並依用戶端的資料管理方式還原資源。
- 記下錯誤訊息中的檔名，例如
geosite.dat、geoip.dat，以及完整路徑。不要只憑用戶端安裝目錄推測資源位置。 - 確認檔案可讀取且不是空檔。Linux 的檔名有大小寫之分，目錄權限也會影響核心讀取檔案。
- 透過用戶端提供的資料更新入口，還原相容的資料檔；若介面沒有這個入口，請依該用戶端的資源管理方式處理，不要任意混用不同格式。
- 若檔案存在但日誌顯示找不到分類，請檢查
geosite:後的分類拼字和目前資料內容。第三方分類名稱並非每個資料檔都包含。 - 備份後暫時移除有問題的單一規則，再測試啟動。若能啟動，只代表問題範圍已縮小至該規則或資源；恢復正式設定前，仍須補齊資料與規則。
排查期間若刪除所有分流規則，會改變請求的路由方向，可能將原本應直連的請求交給代理，也可能讓代理請求改走直連出站。找出問題後，請還原原有路由設定，並確認 outboundTag 對應到實際存在的出站標籤。
七、Android 服務異常與修復後驗證
v2rayNG 在 Android 上透過系統 VPN 介面接收流量。VPN 授權失敗與 Xray 設定解析失敗屬於不同層次：前者應檢查系統授權、其他 VPN 服務和裝置政策；後者仍須回到日誌檢查 JSON、協定或資源問題。v2flyNG 使用 V2Fly 核心，排查時也應區分這兩類問題。
- 服務啟動後隨即停止：先檢查啟動日誌中的第一則錯誤，再確認系統 VPN 授權是否完成；不要只依狀態列圖示判斷原因。
- 其他 VPN 正在執行：先停止互相衝突的 VPN 服務。在同一個 Android 使用者帳戶下，通常只能有一個啟用中的 VPN 服務接管流量。
- 鎖定螢幕後才中斷：若啟動時正常，背景執行一段時間後才停止，請檢查系統的電池最佳化與背景執行限制；這並非典型的設定讀取失敗。
- 服務正在執行但沒有流量：檢查應用程式代理範圍、DNS、路由，以及目前節點是否可連線。系統 VPN 介面已啟用，不代表每個應用程式的請求都已送往目標出站。
修正完成後，請使用相同節點和相同測試條件再次確認。先確認核心不會立即退出，再確認本機監聽或 Android VPN 服務正常，最後才測試網頁連線。系統代理、VPN 接入和核心程序分屬不同環節，單一環節正常不足以證明整條連線路徑可用。
-
重新啟動確認
停止服務後重新啟動一次，確認原本的錯誤不再出現；若改為出現另一則錯誤，請依新錯誤所屬階段繼續排查。
-
確認接入狀態
桌面端請確認實際監聽連接埠與系統代理設定；Android 請確認 VPN 服務及應用程式範圍。若連接埠有變更，請更新所有手動設定的接入項目。
-
送出請求
使用瀏覽器開啟已知可正常連線的 HTTPS 網頁，同時觀察日誌是否出現對應請求。若只有遠端逾時，應改查節點與網路，不要再反覆修改 JSON 標點。
-
還原設定
還原排查期間暫時調整的路由和日誌層級，並保存最終設定副本。記錄「錯誤原文、修改項目、驗證結果」，方便下次更新後比對。