本文適合遇到 v2rayN 啟動失敗、10808 連接埠被佔用、瀏覽器代理無回應或核心反覆退出的使用者。排查從確認監聽位址開始，再分別使用 Windows、macOS 與 Linux 的系統工具找出佔用程序，最後依實際情況關閉舊程序或更換連接埠，並同步修改系統代理、瀏覽器與應用程式代理設定。
先確認是否真的發生連接埠衝突
V2Ray、Xray 等核心需要在本機建立入站監聽，瀏覽器和其他應用程式再將要求交給這個監聽連接埠。常見設定會使用 127.0.0.1:10808 提供 SOCKS 代理，並用 127.0.0.1:10809 提供 HTTP 代理。實際連接埠由用戶端設定決定，並非所有版本都固定相同。
連接埠衝突的本質，是兩個程序嘗試監聽相同位址、相同傳輸協定與相同連接埠。例如舊的 v2rayN 核心尚未退出，新啟動的核心再次繫結 127.0.0.1:10808，系統就會拒絕第二次監聽。此時訂閱、VMess、VLESS 與路由規則通常不是優先檢查項目。
錯誤：listen tcp 127.0.0.1:10808: bind: address already in use
原因與解法：已有程序佔用 TCP 10808。先查出對應的 PID，確認程式身分後正常退出舊程序，或將新用戶端改用未佔用的連接埠。
錯誤：Only one usage of each socket address is normally permitted
原因與解法：Windows 拒絕重複繫結同一個通訊端位址。檢查是否重複啟動 v2rayN、殘留核心，或同時執行另一套本機代理。
現象：核心顯示正在執行，但瀏覽器一直顯示代理伺服器無回應
原因與解法：不一定是佔用問題，瀏覽器可能仍指向舊連接埠。對照用戶端目前的監聽值，確認 HTTP 與 SOCKS 類型是否選取正確。
在 Windows 找出佔用 10808 的程序
Windows 11 與 Windows 10 都可以使用系統內建的 netstat 查看監聽程序。先完全退出準備啟動的 v2rayN，再開啟終端機執行檢查，這樣能降低將目前新程序誤判為衝突程序的可能性。
查詢監聽記錄
開啟 PowerShell 或命令提示字元，執行
netstat -ano | findstr :10808。重點查看狀態為LISTENING的列，並記下最右側的 PID。確認程序名稱
執行
tasklist /FI "PID eq 程序編號"，將命令中的程序編號替換為實際 PID。也可以在工作管理員的「詳細資料」頁面依 PID 尋找。判斷是否可以退出
如果結果是先前遺留的 v2rayN 或其核心程序，先從系統匣選單正常退出。若屬於其他仍在使用的程式，不要直接結束，優先替其中一個用戶端更換連接埠。
再次確認連接埠
再次執行查詢命令。沒有
LISTENING記錄後啟動 v2rayN，並檢查日誌中是否已出現成功監聽的訊息。
netstat -ano | findstr :10808
tasklist /FI "PID eq 6420"
PowerShell:
Get-NetTCPConnection -LocalPort 10808 -State Listen
Get-Process -Id 6420如果查詢結果出現多個連線狀態，不要將 ESTABLISHED、TIME_WAIT 視為監聽程序。真正需要確認的是 LISTENING，或 PowerShell 輸出中的 Listen。連線狀態列代表已有連線活動，最右側的 PID 仍可協助確認實際使用者。
結論：先辨識 PID，再處理程序
結束程序不是固定步驟。PID 對應舊核心時可以正常退出；若對應開發伺服器、遠端連線工具或仍在運作的代理程式，改用其他 v2rayN 本機連接埠通常更穩妥。
在 macOS 與 Linux 檢查監聽程序
macOS 和 Linux 都可以使用 lsof 查看連接埠，但 Linux 發行版通常也提供 ss。在 Debian、Ubuntu、Fedora 等系統中，一般使用者可能看不到其他帳戶啟動的完整程序資訊，確認權限範圍後再使用 sudo。
macOS:
lsof -nP -iTCP:10808 -sTCP:LISTEN
Linux:
ss -ltnp | grep ':10808'
sudo lsof -nP -iTCP:10808 -sTCP:LISTEN錯誤：listen tcp 0.0.0.0:10808: bind: address already in use
原因與解法：已有程式在所有 IPv4 介面監聽 10808。透過 ss -ltnp 或 lsof 找出 PID，再決定停止對應的使用者服務或修改用戶端連接埠。
現象：lsof 沒有輸出，但用戶端仍顯示 10808 被佔用
原因與解法：確認用戶端實際錯誤是否涉及 UDP、IPv6 或其他連接埠，再分別查詢 [::]:10808、UDP 監聽項目，以及日誌中的完整位址。
- macOS：在「活動監視器」中依 PID 搜尋，確認程序路徑與啟動使用者；關閉圖形化用戶端時，也要檢查選單列中的背景執行狀態。
- Linux 桌面：如果用戶端透過 systemd 使用者服務啟動，關閉視窗不一定會停止服務，可以使用
systemctl --user status查看目前使用者服務狀態。 - Linux 多使用者環境：監聽位址為
0.0.0.0時會涵蓋所有 IPv4 網卡，不應只檢查127.0.0.1。 - 容器環境：容器映射至主機的 10808 也會造成佔用，命令顯示的程序可能是容器執行環境，而非代理核心名稱。
關閉舊程序還是修改監聽連接埠
處理方式取決於佔用者是否仍有用途。舊核心殘留、重複開啟用戶端或異常退出產生的孤立程序，可以確認身分後關閉。若連接埠屬於另一項持續執行的服務，應保留該服務，並為 v2rayN 選擇新的本機連接埠。
修改時不要只改一項設定。SOCKS、HTTP、區域網路監聽和 API 連接埠可能分開設定；其中任兩項意外使用相同位址與連接埠，都可能導致核心啟動失敗。選擇新連接埠後，還要檢查系統代理與應用程式代理是否一併更新。
記錄目前設定
在 v2rayN 主介面開啟「設定」→「參數設定」，記錄本機 SOCKS、HTTP 與允許區域網路連線的相關值。不同版本的分組名稱可能略有差異，請以連接埠欄位為準。
選擇未使用的連接埠
先使用系統命令查詢候選連接埠，例如 10810 或 10811。確認沒有監聽記錄後，再寫入用戶端，避免只因連接埠看起來陌生就直接使用。
儲存並重新啟動核心
儲存參數後重新啟動核心，或退出並重新開啟 v2rayN。接著查詢新連接埠，確認對應的 PID 已進入監聽狀態。
重新設定代理入口
如果系統代理未由 v2rayN 自動接管，應將原本的
127.0.0.1:10808改為新連接埠；瀏覽器擴充功能和獨立應用程式也要逐一同步。保留位址範圍
僅供本機使用時，維持監聽位址為
127.0.0.1。只有明確需要讓區域網路裝置連線時，才啟用對應的區域網路監聽選項。
| 情境 | 建議處理方式 | 後續檢查 |
|---|---|---|
| 舊 v2rayN 核心殘留 | 正常退出舊程序，再啟動目前的用戶端 | 確認 10808 是否由新的 PID 監聽 |
| 另一項本機服務長期佔用 | 保留原服務，將代理改至 10810 等未使用的連接埠 | 系統代理與瀏覽器連接埠 |
| 兩個 v2rayN 執行個體同時運作 | 只保留需要的執行個體，或為兩者設定不同連接埠 | 系統匣圖示與啟動項目 |
| 區域網路監聽涵蓋本機位址 | 確認是否確實需要監聽所有介面 | 0.0.0.0 與 127.0.0.1 的繫結範圍 |
結論：長期服務應保留，殘留程序應退出
衝突程序仍在執行工作時，修改本機代理連接埠；若衝突源自重複啟動或舊核心，清理啟動來源比不斷更換連接埠更有效。
同步更新系統代理與瀏覽器設定
解決連接埠衝突後仍無法存取，最常見的原因是流量仍送往舊連接埠。用戶端顯示新連接埠 10810，不代表瀏覽器、命令列工具和系統代理已自動改用 10810。每個曾手動設定代理的入口都需要個別確認。
| 使用位置 | 應確認的內容 | 常見錯誤 |
|---|---|---|
| Windows 系統代理 | 位址為 127.0.0.1，連接埠與目前 HTTP 入站設定一致 | 將 SOCKS 連接埠填入僅接受 HTTP 的欄位 |
| 瀏覽器獨立代理 | 代理類型、主機與連接埠三項一致 | 擴充功能仍儲存舊的 10808 |
| 命令列環境變數 | HTTP_PROXY、HTTPS_PROXY 與 ALL_PROXY |
終端機工作階段未重新載入變數 |
| 區域網路上的其他裝置 | 填寫執行用戶端電腦的區域網路位址與新連接埠 | 誤填 127.0.0.1，實際上會指向裝置本身 |
現象：切換至 10810 後核心運作正常，但網頁立即拒絕連線
原因與解法：應用程式仍連線至舊的 10808，或將 SOCKS 類型當成 HTTP 使用。重新選擇代理類型，並將所有手動設定的入口統一指向目前的監聽值。
現象：瀏覽器可用，但終端機命令仍無法連線
原因與解法：瀏覽器與終端機使用不同的代理來源。檢查目前終端機工作階段中的代理環境變數，修改後重新開啟終端機再測試。
v2rayNG 和 v2flyNG 在 Android 上通常由應用程式自行管理本機代理與 VPN 接管流程。若匯入相同訂閱後發生連線問題，不應直接套用桌面系統的 PID 命令；先檢查是否同時啟用了另一個 VPN 連線，再確認用戶端設定中的本機連接埠與執行狀態。
修復完成後的驗證順序
驗證應從本機監聽開始，而不是直接判斷節點失效。只要本機連接埠尚未建立，後續的協定交握、傳輸層連線與路由分流都不會發生。先確認應用程式能連線至本機代理，再檢查節點參數與遠端網路。
確認唯一的監聽程序
再次執行
netstat、lsof或ss。目標連接埠應由預期的核心 PID 監聽，不應同時出現無法解釋的第二個服務。檢查用戶端日誌
啟動後觀察 30 秒，確認沒有新的
address already in use、重複重新啟動或建立入站失敗的訊息。測試本機代理
讓瀏覽器或命令列明確連線至目前的連接埠。若立即收到拒絕連線，問題仍在本機監聽；若建立連線後逾時，再檢查節點與網路。
確認分流結果
確認路由規則沒有將測試目標錯誤送往直連或阻斷出站。修復連接埠不會自動變更 geosite、geoip、domain 等規則。
重新檢查自動啟動
重新啟動或再次登入系統後再檢查一次。如果舊連接埠重新被佔用，表示仍有登入啟動項目或使用者服務在背景啟動舊執行個體。
如果連接埠已正常監聽，但所有節點仍然逾時，應轉向網路與設定層排查：確認系統時間、節點位址、協定參數、傳輸設定以及訂閱是否有效。連接埠衝突只發生在本機入站階段，無法解釋核心成功接收連線後的所有連線故障。