01 / LOCAL CHAIN
已連線但無法上網：先檢查本機鏈路
先將「無法上網」拆解成可驗證的現象
用戶端顯示「已連線」通常只代表設定已交由核心執行，不表示瀏覽器、終端機及其他應用程式都能透過節點成功存取目標網址。先關閉系統代理或停止目前設定，確認裝置透過原始網路能否存取平時穩定的網站。若直連也失敗，應先處理路由器、無線網路、網卡或電信網路問題；若直連正常、啟用用戶端後全部失敗，故障範圍才會集中在本機代理、路由規則或遠端節點。
接著分別測試瀏覽器與命令列。瀏覽器能存取但終端機失敗，多半是兩類應用程式讀取代理設定的方式不同；瀏覽器與終端機都失敗，則繼續檢查本機連接埠與核心日誌。還要區分「所有網域都打不開」和「少數網站失敗」：前者較像本機代理或節點鏈路中斷，後者常與分流、DNS 及目標網站的網路策略有關。記錄準確現象，比反覆點擊連線按鈕更有價值。
確認核心程序與本機監聽連接埠
v2rayN、v2rayNG 與 v2flyNG 都需要啟動對應核心並建立本機入口。桌面版可在用戶端狀態區查看目前設定是否正在執行，再到設定中確認 HTTP、SOCKS 或混合代理連接埠。不要猜測教學中常見的數字；實際連接埠可能已被修改，也可能因遭其他程式佔用而啟動失敗。Windows 可使用以下指令檢查連接埠，其中的連接埠號碼應替換為用戶端介面顯示的實際值：
netstat -ano | findstr LISTENING
Get-NetTCPConnection -State Listen | Sort-Object LocalPort若清單中沒有對應連接埠，請回到用戶端日誌尋找「address already in use」、「failed to listen」或設定載入失敗等訊息。連接埠被佔用時，可關閉佔用程式，或在用戶端設定中改用尚未使用的連接埠，再完全停止並重新啟動核心。只修改設定而不重啟核心，舊程序可能仍佔用原連接埠，但系統代理已指向新連接埠，形成表面連線、實際沒有流量的錯位狀態。
核對系統代理指向與路由模式
系統代理啟用後，應指向本機回送位址與目前的監聽連接埠。Windows 中常見的目標是 127.0.0.1，不應誤填區域網路網卡位址；若用戶端提供「自動設定指令碼」、「全域代理」與「清除系統代理」等選項，應明確確認目前使用哪一種。自動設定指令碼依賴規則判斷目標位址，全域代理則會將支援系統代理的請求統一送至本機入口，兩者的故障表現不同。排查時可暫時切換至規則較少的模式驗證基礎鏈路，確認可用後再恢復原有分流。
自訂路由規則也可能將目標流量送往錯誤的出站。特別要檢查規則順序，因為核心通常會依先匹配、先套用處理；一條範圍過大的直連規則若排在前面，會遮蔽後方的代理規則。反過來，將區域網路位址送往遠端，也可能導致印表機、路由器管理頁面或內部服務無法存取。建議暫時停用新增規則，只保留用戶端預設規則進行比較，不要直接刪除原設定。測試成功後逐條恢復，才能找出真正造成影響的規則。
使用本機代理請求確認資料是否進入核心
在桌面版中，可以繞過系統代理，直接指定用戶端的本機連接埠發出請求。如此可區分「系統代理未生效」與「節點本身無法使用」。以下範例假設 HTTP 代理連接埠為 10809；實際執行時必須使用用戶端目前的連接埠：
curl.exe -I --proxy http://127.0.0.1:10809 https://example.com/
curl.exe -v --proxy http://127.0.0.1:10809 https://example.com/若直接指定代理可以取得 HTTP 回應，而瀏覽器仍然失敗，應將重點轉向瀏覽器代理策略、擴充功能衝突或系統代理設定；若指令立即提示無法連線至 127.0.0.1，表示本機連接埠未監聽或填寫錯誤；若已連線至本機連接埠但等待後逾時，表示請求已進入核心，下一步應檢查節點握手、DNS 與路由日誌。最好同時觀察日誌中的入站、路由命中與出站錯誤三部分，不要只看最後一行錯誤。
完成排查後，將系統代理恢復為明確狀態。若暫時不再使用用戶端，應先執行用戶端的「清除系統代理」再退出；若仍需連線，則確認系統代理連接埠與目前核心一致。異常退出可能留下舊代理位址，造成下次開機後所有讀取系統代理的應用程式無法連網。此時重新開啟用戶端並清除系統代理，通常比在多個系統面板中反覆修改數值更直接。
02 / REMOTE HANDSHAKE
節點逾時與握手失敗：定位中斷層級
區分 TCP 逾時、TLS 錯誤與協定拒絕
「節點逾時」並非單一原因。連線可能在建立 TCP 前就中斷，也可能已連至伺服器但 TLS 握手失敗，或 TLS 成功後遭 VMess、VLESS、Trojan 等協定層拒絕。應依據日誌區分這三類問題。出現 i/o timeout、context deadline exceeded 或連線目標位址逾時時，先檢查網路可達性；出現憑證網域、握手或 serverName 相關錯誤時，檢查系統時間與 TLS 參數；出現驗證失敗、無效使用者或協定回應異常時，再核對連接埠、使用者識別碼與傳輸設定。
不要只根據用戶端測速清單中的顏色判斷節點狀態。測速可能只測試 TCP 建立連線，也可能測試完整請求，不同用戶端與測試方式不能直接橫向比較。較可靠的方法是選擇一個節點，固定目前網路與路由模式，發出一次實際請求，同時觀察從解析目標位址、建立連線到完成握手的完整日誌。重複測試時保持其他條件不變，才能判斷錯誤是否穩定。
先檢查目標主機與連接埠是否可達
Windows 可使用 PowerShell 的 Test-NetConnection 檢查節點網域與連接埠。此指令只驗證基礎網路連線，不代表上層協定設定正確，但能快速排除連接埠完全無法連線的情況：
Resolve-DnsName node.example.com
Test-NetConnection node.example.com -Port 443
Test-NetConnection node.example.com -InformationLevel Detailed若網域無法解析，請轉到 DNS 章節；若解析到位址但 TCP 測試失敗，可換另一個網路再次測試，例如從家用網路切換至行動網路。僅某個網路失敗，通常表示鏈路路徑、路由器策略或網路出口存在差異；所有網路都失敗，則需要確認節點位址、連接埠與伺服器狀態。測試時不能把網站的一般 HTTPS 連接埠結果當作節點連接埠結果，兩者必須是同一個目標主機與同一個連接埠。
若節點使用網域，避免直接將解析出的 IP 填回設定作為長期方案。TLS 連線通常依賴網域完成憑證驗證與 SNI 比對，直接改成 IP 可能讓原本的 TCP 可達性問題變成新的憑證錯誤。暫時使用 IP 只適合判斷 DNS 是否涉及故障，測試完成後應恢復原始網域與對應的 serverName。
核對系統時間、SNI 與憑證網域
TLS 驗證依賴裝置時間。系統日期、時區或自動校時異常時，憑證可能被判定為尚未生效或已經過期。先在系統設定中啟用自動設定時間與自動時區，再手動同步一次；虛擬機、雙系統切換及長時間休眠後的裝置尤其需要檢查。校時後應完整重啟用戶端核心，因為部分連線與工作階段可能仍保留舊的時間條件。
serverName 或 SNI 必須對應伺服器憑證涵蓋的網域，不一定與連線位址欄位完全相同。訂閱匯入後若曾手動編輯節點，應對照原始節點參數檢查位址、連接埠、傳輸方式、TLS 開關、SNI、路徑與主機標頭是否仍成組匹配。只複製位址與連接埠、遺漏傳輸參數，是常見的握手失敗原因。相關排查也可參閱TLS 握手失敗與憑證錯誤處理。
逐項比對協定與傳輸參數
協定層參數必須整體一致。VMess 需要正確的使用者識別碼、加密與傳輸組合；VLESS 需要核對使用者識別碼、流量控制及安全層設定；Trojan 需要核對驗證內容與 TLS 入口；Shadowsocks 則要確認加密方式與驗證內容成對匹配。WebSocket、gRPC、TCP 等傳輸方式也各自帶有路徑、服務名稱、Host 或安全層欄位。任何一項被空格、換行或手動替換破壞，都可能表現為連線後立即關閉。
最有效的比較方式，是重新從訂閱匯入至獨立分組，不覆蓋現有手動設定，然後測試新匯入的節點。若新節點可用，表示舊節點在編輯或遷移過程中產生了參數偏差；若新舊節點錯誤一致，應檢查訂閱來源、網路環境或遠端狀態。不要在不了解含義時啟用略過憑證驗證作為固定方案；它可能暫時掩蓋時間、網域或憑證部署問題，卻無法修復協定參數不一致。
| 日誌階段 | 常見現象 | 優先檢查 |
|---|---|---|
| 解析前 | 找不到主機、解析失敗 | DNS、網域拼寫、網路連線 |
| TCP 建立連線 | 逾時、連線遭拒 | 節點位址、連接埠、基礎可達性 |
| TLS 握手 | 憑證網域或時間錯誤 | 系統時間、SNI、TLS 開關 |
| 協定驗證 | 連線後立即關閉 | 使用者參數、流量控制、傳輸組合 |
若同一節點時而成功、時而逾時，還應檢查本機網路丟包、無線訊號切換及裝置從休眠恢復的情況。連續執行少量測試並記錄發生時間，不要用高頻並行測試製造額外負擔。穩定出現的錯誤按設定排查，會隨網路切換而變化的錯誤則按鏈路排查，這種分類能大幅縮短定位時間。
03 / SUBSCRIPTION INPUT
訂閱更新失敗：從位址、回應到節點解析
確認訂閱位址完整，且沒有混入多餘字元
訂閱失敗首先要區分「沒有取得回應」與「取得回應但解析失敗」。從聊天工具、文件或 QR Code 複製位址時，結尾可能混入句號、空格、換行或全形字元；有些位址還包含很長的查詢參數，複製不完整會讓伺服器回傳登入頁、錯誤頁或空內容。應在用戶端訂閱設定中重新貼上完整位址，檢查協定標頭、網域、路徑與查詢參數是否連續，並確認沒有把節點分享連結誤貼進訂閱位址欄。
v2rayN 通常以訂閱分組管理多個來源，v2rayNG 與 v2flyNG 則在訂閱設定中維護位址。修改訂閱後，需要儲存設定並主動執行更新；只編輯名稱不會觸發抓取。為避免舊快取干擾，可以建立暫時分組，使用同一個位址更新並觀察結果。新分組成功而舊分組失敗時，應重點檢查舊分組的更新設定、篩選條件與快取狀態。
讀取 HTTP 狀態與回應類型
若日誌出現 HTTP 狀態碼，應依回應含義處理。驗證失敗或禁止存取通常與位址中的授權參數、帳戶狀態或來源限制有關；找不到資源通常表示路徑不完整或位址已變更；伺服器錯誤則應稍後重試，並確認是否只有該訂閱來源異常。收到成功狀態也不代表內容一定可解析，因為回應可能是網頁、登入提示或閘道說明，而不是訂閱資料。
桌面版可在不顯示位址內容的前提下，使用指令確認請求過程。訂閱位址通常包含敏感授權參數，不應將完整位址貼到公開日誌或截圖中。以下指令中的位址只是示意值，實際測試時僅在本機終端機使用自己的訂閱位址：
curl.exe -I "https://subscription.example/subscription"
curl.exe -L --connect-timeout 15 "https://subscription.example/subscription" -o subscription.txt-I 只讀取回應標頭，適合檢查重新導向與狀態；部分訂閱服務不支援只取得回應標頭，此時應使用第二條指令儲存回應，再確認檔案是否為空及內容類型是否合理。不要直接公開回應檔案，因為其中可能包含節點位址與驗證參數。若請求發生多次重新導向，應確保用戶端支援該流程，並確認最終位址仍屬於預期的訂閱入口。
判斷更新請求是否需要經過目前代理
訂閱更新與節點連線是兩條相關但不同的鏈路。有些用戶端可選擇「透過代理更新訂閱」，此選項要求目前已存在可運作的節點；若唯一節點已失效，更新請求又被強制送入該節點，就會形成無法更新的閉環。排查時可先關閉代理更新，透過原始網路請求訂閱；若原始網路無法連線而已有可用節點，再反向測試透過代理更新。
系統代理殘留也會影響訂閱請求。用戶端已退出但系統仍指向舊的本機連接埠時，在重新啟動用戶端前發出的網路請求可能全部失敗。先確認本機連接埠正在監聽，或清除系統代理後再更新。企業網路與需要網頁登入的公共網路，還可能在首次存取時回傳驗證頁面；應先用瀏覽器完成目前網路的正常連線，再發出訂閱請求。
處理格式、編碼與節點篩選問題
訂閱回應可能包含編碼後的節點集合，也可能包含逐行的分享連結。用戶端必須識別回應格式，才能產生節點清單。出現「解析成功但節點數為零」時，不要立即認定訂閱為空，應檢查是否啟用了關鍵字篩選、去重、只保留指定協定或刪除無效節點等規則。過於嚴格的篩選條件可能排除所有項目，尤其是在分組名稱或節點備註變更後。
若日誌明確提示某一行格式錯誤，可先確認整體更新是否仍匯入其他有效節點。有些用戶端會略過單筆異常記錄，有些則會終止整個處理程序。重新取得一次回應可排除傳輸中斷；若持續在相同位置失敗，就需要訂閱來源修正對應項目。不要長期手動解碼並維護訂閱副本，因為節點參數更新時副本不會同步，之後會逐漸出現位址、憑證網域與傳輸參數不一致的問題。
建立可重複的訂閱檢查流程
完整流程應為：檢查系統時間與基礎網路，核對訂閱位址，確認更新是否經過代理，查看 HTTP 回應，再檢查解析日誌與篩選條件，最後選擇新匯入的節點進行實際連線測試。更新後只看到節點名稱，不足以證明可用；應檢查節點參數是否完整，並完成一次存取驗證。詳細入口操作可參閱v2rayN 與 v2rayNG 訂閱匯入說明。
頻繁自動更新失敗時，還要檢查裝置休眠、背景限制與網路切換。桌面裝置在休眠期間不會依排程執行更新，恢復後用戶端可能需要重新建立網路；Android 裝置若背景活動受限，定時工作也可能延後。應將自動更新視為維護功能，而不是連線成功的唯一前提：始終保留最近一次可運作的設定，並在更新後觀察日誌與節點變化。
04 / THROUGHPUT
連線速度緩慢：區分節點、線路與本機負載
先判斷慢在建立連線，還是持續傳輸
開啟網頁等待很久，但下載開始後速度正常，通常是 DNS、首次握手或連線重用問題；網頁很快出現但大型檔案持續傳輸緩慢，更可能與線路頻寬、丟包、伺服器負載或裝置效能有關；只有影片、即時通訊或某個應用程式速度慢，則應檢查該應用程式使用 TCP 還是 UDP，以及路由規則是否將相關網域分散到不同出站。把所有情況統稱為「節點慢」，會遺漏關鍵差異。
測試前先固定環境：選擇同一個節點、同一個網路、同一個目標資源與相近時段，關閉佔用頻寬的同步與下載工作。不要同時開啟多個測速工具，因為並行請求會爭用頻寬並改變節點負載。先測試原始網路，再啟用用戶端測試，兩組結果可用來判斷瓶頸是否已存在於本機接入。若原始網路本身波動明顯，應先改善無線訊號、網路線連線或路由器狀態。
使用可重複的請求觀察各階段耗時
curl 可以分別輸出解析、連線、TLS 與總耗時，用來判斷緩慢出現在哪個階段。以下範例透過本機 HTTP 代理存取保留的示例網域，連接埠應改為用戶端的實際值：
curl.exe -o NUL -s -w "dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} start=%{time_starttransfer} total=%{time_total}\n" --proxy http://127.0.0.1:10809 https://example.com/解析耗時高時轉查 DNS；連線耗時高時關注遠端位址可達性與線路距離；TLS 耗時異常可能與丟包、憑證鏈處理或網路重傳有關；首位元組速度慢而連線階段正常，可能是目標網站回應或遠端出口負載所致。單次結果不能代表長期表現，應間隔執行幾次並觀察是否穩定，不必追求大量樣本。排障目標是找出耗時集中在哪一段，而不是產生排名。
比較節點時只變更節點本身
同一訂閱中的節點可能使用不同地區、協定、傳輸方式與出口線路。比較時保持用戶端模式、DNS 與目標位址不變，逐一切換節點完成相同請求。若所有節點都很慢，優先檢查本機網路、用戶端模式、DNS 與裝置資源；只有某個節點緩慢，問題較集中於該節點路徑或遠端負載；同一節點在不同網路間差異明顯，則需要考慮兩條接入網路到節點之間的路由品質。
用戶端的延遲測試只反映測試方式涵蓋的階段，低延遲不保證大量資料傳輸速度，高延遲也不一定導致持續吞吐量很低。TCP 發生丟包時會降低傳送視窗，表現為速度週期性下降；無線干擾、行動網路切換與跨區域鏈路都可能觸發此現象。實際使用時應同時觀察連線穩定性、網頁首位元組與持續傳輸，不要只依據單一延遲值選擇節點。
檢查路由規則是否讓同一項服務走不同路徑
現代網頁會同時請求主網域、靜態資源網域、API 網域與內容傳遞位址。如果規則只匹配主網域，附屬資源可能直連或走另一個出站，頁面就會出現主體載入很快、圖片或指令碼長時間等待的情況。開啟核心存取日誌，觀察同一次頁面載入中各網域命中的出站規則。發現路徑分散後，應依業務網域群組調整規則，而不是不斷將單一網域追加到清單末尾。
規則順序同樣會影響效能。過多正規表示式、範圍寬泛的網域匹配與重複規則會增加判斷複雜度，也讓維護更加困難。應優先使用清楚的網域、尾碼、IP 範圍與內建資料集規則，將高確定性的規則放在前面，預設規則放在最後。調整後清除 DNS 快取並重新啟動核心，避免舊解析與舊連線繼續沿用原本路徑。
評估傳輸、連線重用與裝置資源
連線重用可以減少頻繁建立連線的成本，但並非所有網路與伺服器組合都適合。若少量連線正常、並行後卻明顯卡頓，可比較啟用與停用重用的結果。不要盲目提高並行數；裝置效能有限時，更多並行會增加加密、上下文切換與記憶體壓力。Android 裝置在省電或溫度較高時，背景處理能力也可能降低；桌面版則應觀察 CPU、記憶體與磁碟是否長期被其他工作佔用。
不同傳輸方式具有不同的封裝成本，但設定正確與鏈路穩定通常比理論成本更重要。不要為追求速度而單獨修改傳輸欄位，因為用戶端與伺服器參數必須一致。若要比較協定組合，應使用訂閱中已提供且確認可用的完整節點，而不是從一個節點複製位址後自行拼接另一套傳輸參數。關於協定特性與選擇界線，可閱讀VMess、VLESS、Trojan 與 Shadowsocks 比較。
05 / NAME RESOLUTION
DNS 解析異常：確認網域由哪裡解析
辨識典型 DNS 症狀
DNS 問題常見表現包括輸入網域失敗、直接存取 IP 有回應、首次開啟網站等待很久、同一網域在不同應用程式得到不同結果，或切換用戶端模式後部分網站突然無法使用。節點網域解析失敗會阻止核心連線至遠端；目標網站網域解析失敗則可能只影響特定存取。排查時必須先確認失敗的是「節點位址」還是「存取目標」，兩者使用的解析路徑可能不同。
瀏覽器可能啟用自己的安全 DNS，系統使用另一組伺服器，核心又依設定處理代理請求中的網域，因此同一台裝置上可能同時存在多條 DNS 路徑。瀏覽器成功不能證明系統解析正常，系統指令成功也不能證明核心取得了相同結果。應結合瀏覽器設定、系統網路設定與核心日誌，判斷實際負責解析的元件。
從系統解析結果開始檢查
Windows 可使用 Resolve-DnsName 或 nslookup，macOS 與 Linux 可使用 dig 或 nslookup。先測試節點網域，再測試出現異常的目標網域，並記錄回應類型與位址：
Resolve-DnsName node.example.com
nslookup node.example.com
nslookup example.com
# macOS 或 Linux
dig node.example.com
dig example.com A
dig example.com AAAA指令回傳逾時，表示目前 DNS 伺服器未及時回應；回傳不存在，則要確認網域拼寫與記錄狀態；取得位址後仍無法連線，問題已進入路由、連接埠或握手階段。若同時回傳 IPv4 與 IPv6 位址，而目前網路的 IPv6 連線不完整，應用程式可能先嘗試無法到達的位址並等待回退。可暫時比較 A 與 AAAA 記錄的連線結果，但不要長期透過刪除系統協定支援來掩蓋網路設定問題。
清除快取，避免舊結果干擾
系統、瀏覽器與用戶端核心都可能快取解析結果。修改 DNS 設定後，舊連線與舊快取不會立即消失，因此應依序關閉相關瀏覽器分頁、停止核心、清除系統快取，再重新啟動用戶端。Windows 可執行：
ipconfig /flushdns
Clear-DnsClientCache
Get-DnsClientServerAddress清除快取只能讓下一次請求重新解析，不能修復錯誤的伺服器位址、路由規則或網域設定。若每次清除後短暫恢復正常、隨後又異常，應檢查是哪個元件重新寫入錯誤結果，例如系統網路切換、路由器下發的 DNS、瀏覽器獨立解析，或用戶端規則將請求送往無法到達的伺服器。
理解本機解析、遠端解析與網域規則
當應用程式將網域交給 SOCKS 或 HTTP 代理時，網域可能先由本機解析為 IP，也可能以網域形式進入核心，再由核心選擇解析伺服器。兩種方式會影響路由匹配：若過早轉換為 IP，基於網域的規則可能無法取得原始網域；若始終保留網域，核心就需要可靠的 DNS 出站路徑。設定時應明確決定在哪一層解析，而不是同時疊加多個彼此覆蓋的選項。
核心 DNS 設定通常包含伺服器清單、匹配網域與查詢策略。規則應與出站路徑配套：用於解析節點網域的伺服器，必須在節點尚未建立前就能連線；依賴代理出站的 DNS，不能反過來負責建立該代理所需的首次解析，否則會形成循環依賴。最穩妥的基礎結構，是保留一條能在原始網路上解析節點位址的路徑，再依目標網域與路由需求安排其他查詢。
檢查 hosts、篩選規則與瀏覽器獨立設定
系統 hosts 檔案中的靜態記錄，優先級通常高於一般 DNS 查詢。舊測試記錄、錯誤位址或重複項目，會讓某個網域長期指向過期目標。檢查時只修改自己明確新增的記錄，並在修改前保留副本。安全軟體、路由器篩選、家長控制與企業網路策略，也可能回傳特定位址或阻止查詢，需要切換至另一個網路進行比較。
瀏覽器的獨立 DNS 設定可能繞過系統路徑。如果只有一個瀏覽器異常，先使用乾淨設定或其他瀏覽器測試，再檢查該瀏覽器是否啟用獨立解析、代理擴充功能或快取策略。如果所有應用程式都異常，則優先檢查系統與核心。不要讓瀏覽器擴充功能、系統代理工具與 V2Ray 用戶端同時修改同一層設定，否則即使請求成功，也很難確認實際經過哪條路徑。
| 現象 | 可能位置 | 驗證方法 |
|---|---|---|
| 節點網域無法解析 | 系統 DNS、基礎網路 | 停止用戶端後查詢節點網域 |
| 只有瀏覽器正常 | 瀏覽器獨立 DNS 或系統代理差異 | 比較命令列與瀏覽器設定 |
| 網域失敗、IP 可連線 | 目標網域解析路徑 | 查詢 A 與 AAAA 記錄，並查看核心日誌 |
| 切換網路後恢復 | 目前網路下發的 DNS 或路由 | 記錄兩個網路的伺服器與解析結果 |
修復完成後，應分別驗證節點網域解析、目標網域解析與實際存取，不能只看查詢指令的回傳結果。DNS 回傳位址只代表解析階段完成，後續仍需經過路由、連線與協定握手。將三段結果分開記錄，日後切換網路或調整規則時，更容易找出是哪一層再次發生變化。
06 / APPLICATION ROUTING
系統代理未生效：分別核對瀏覽器與終端機
先了解系統代理的作用範圍
系統代理是一組供應用程式讀取的連線設定，不會自動接管所有網路流量。瀏覽器與部分桌面軟體通常會讀取系統代理；命令列工具、遊戲、背景服務及自行實作網路堆疊的應用程式可能忽略它。因此可能出現瀏覽器經過用戶端、終端機仍然直連的情況，這不一定代表核心故障。排查時應先確認目標應用支援哪種代理方式，再選擇系統代理、環境變數、應用程式內代理或 TUN 模式。
詳細的情境對照可參閱瀏覽器與終端機系統代理排查。本章重點是建立一致的判斷方法：先驗證本機連接埠，再確認系統代理值，接著檢查應用程式是否讀取該值。不要只透過工作列圖示或用戶端選單狀態，推斷流量已經進入核心。
核對代理位址、類型與連接埠
HTTP 代理、SOCKS 代理與混合代理不是同一個概念。應用程式填寫代理時，類型必須與用戶端監聽入口匹配。將 SOCKS 連接埠填入只支援 HTTP 的系統代理欄位，可能直接連線失敗；將 HTTP 連接埠當作 SOCKS 使用，也會出現握手錯誤。優先從用戶端設定複製位址與連接埠，並確認核心重新啟動後仍在監聽。
Windows 可查看目前使用者的代理設定，並透過直接指定代理進行比較：
netsh winhttp show proxy
Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings"
curl.exe -I --proxy http://127.0.0.1:10809 https://example.com/WinHTTP 與一般桌面應用程式使用的代理來源可能不同，netsh winhttp show proxy 的結果不代表瀏覽器一定使用相同設定。需要依具體程式判斷。若直接指定代理成功，而應用程式仍然直連，表示節點與本機連接埠基本可用，後續應集中檢查應用程式設定；若直接指定代理也失敗，則回到本機監聽或節點章節處理。
終端機工具使用環境變數時，要同時處理大小寫
許多命令列程式會讀取 HTTP_PROXY、HTTPS_PROXY 與 ALL_PROXY，但不同工具對變數大小寫與協定支援有所差異。暫時設定適合單次測試，關閉目前終端機後便會自動失效。PowerShell 範例：
$env:HTTP_PROXY="http://127.0.0.1:10809"
$env:HTTPS_PROXY="http://127.0.0.1:10809"
curl.exe -I https://example.com/
Remove-Item Env:HTTP_PROXY
Remove-Item Env:HTTPS_PROXYmacOS 或 Linux 的 shell 可使用：
export HTTP_PROXY="http://127.0.0.1:10809"
export HTTPS_PROXY="http://127.0.0.1:10809"
export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"
curl -I https://example.com/
unset HTTP_PROXY HTTPS_PROXY http_proxy https_proxy若使用 SOCKS 入口，應確認工具支援相應寫法，以及網域是在本機解析還是由代理端解析。環境變數不應長期殘留在無法保證用戶端常駐的啟動檔案中，否則用戶端未執行時，終端機網路會全部指向空的連接埠。需要永久設定時，應同時記錄清除方法，並確保連接埠不會隨設定切換而變更。
檢查自動設定指令碼與略過清單
自動代理設定會依 URL 或主機名稱決定直連或使用代理。指令碼位址無法載入、快取未重新整理或規則遺漏時，部分網站可能繞過用戶端。排查時可暫時切換至明確的手動代理設定，確認本機連接埠與節點可用後，再恢復自動指令碼。恢復後應重新啟動瀏覽器，使其重新讀取系統設定與指令碼內容。
略過清單通常包含本機位址、區域網路主機或指定網域。範圍過寬會讓大量目標直連，例如錯誤的萬用字元規則可能匹配所有子網域。反之，未略過區域網路位址可能導致內部裝置無法存取。檢查時優先保留回送位址與明確的內網範圍，再逐條恢復自訂項目。系統設定、用戶端規則與瀏覽器擴充功能都可能各自擁有略過清單，應避免在三處重複維護。
TUN 模式的檢查重點不同
TUN 模式透過虛擬網路介面處理更多不讀取系統代理的流量，但也會引入路由表、DNS 接管、系統權限及其他網路軟體衝突等新變數。啟用後若完全斷網，先查看虛擬介面是否建立成功、預設路由是否寫入、DNS 是否指向有效入口，以及用戶端是否取得所需系統權限。退出用戶端後，還應確認路由與 DNS 已恢復。
不要把 TUN 模式作為系統代理失敗時的第一步。先證明節點與一般本機代理連接埠可用，再啟用 TUN，才能將新問題限定在虛擬介面層。若裝置同時執行虛擬機網路、容器網路、企業接入軟體或其他接管路由的程式，應逐一停用進行比較。衝突通常來自路由優先順序與 DNS 接管順序，而不是節點協定本身。
最終驗證應涵蓋三類請求：瀏覽器讀取系統代理、命令列明確指定代理，以及不支援系統代理的應用程式透過自身設定或 TUN 存取。三條路徑分別成功，才能表示設定邊界清楚。某一類失敗時，只處理對應入口，不必重設其他已正常運作的部分。
07 / CLIENT RUNTIME
用戶端閃退或核心退出：保留證據後分層復原
區分介面退出、核心退出與設定載入失敗
用戶端視窗消失、介面仍在但連線停止、點擊啟動後立即回到未執行狀態，分別對應不同層級。介面程序崩潰時，系統匣圖示也可能消失；核心退出時，介面通常仍在且能看到錯誤日誌；設定載入失敗則常發生在切換節點或修改設定後，核心尚未開始監聽連接埠就結束。先記錄是哪一層退出，再決定查看應用程式日誌、核心日誌或系統事件。
發生異常後不要立即反覆重裝。先儲存錯誤時間、操作步驟與日誌末尾內容，並記錄崩潰前是否剛匯入訂閱、編輯路由、切換核心設定、從休眠恢復或更新系統。能穩定重現的步驟，比模糊的「偶爾閃退」更容易定位。公開求助時應刪除節點位址、訂閱參數、使用者識別碼及其他連線憑證，只保留錯誤類型與呼叫階段。
從最後一次設定變更開始回退
若問題在匯入新節點後出現，切換回已驗證節點；在修改路由後出現，則暫時停用新增規則；在調整連接埠後出現，檢查新連接埠是否被佔用；在啟用 TUN 後出現，先恢復一般系統代理模式。一次只回退一類設定，並在每次回退後重新啟動用戶端。直接刪除所有設定雖然可能暫時恢復，卻會失去定位依據，也可能讓同一錯誤在重新匯入後再次發生。
設定檔為 JSON 時，常見錯誤包括尾隨逗號、缺少引號、欄位層級錯誤，以及將數字寫成無法識別的文字。以下是結構完整的最小路由片段範例，用於說明陣列、物件與逗號位置；實際設定仍需與用戶端產生的完整結構合併：
{
"routing": {
"domainStrategy": "AsIs",
"rules": [
{
"type": "field",
"ip": [
"geoip:private"
],
"outboundTag": "direct"
},
{
"type": "field",
"domain": [
"geosite:private"
],
"outboundTag": "direct"
}
]
}
}不熟悉完整設定結構時，優先透過用戶端介面編輯，不要將片段直接覆蓋整個設定檔。用戶端產生的欄位還會引用入站與出站標籤，標籤名稱不一致也會導致啟動失敗。若日誌指出具體欄位或行號，應針對該位置檢查上一層物件，而不是只修改報錯字元。
檢查連接埠、權限與執行目錄
核心啟動後立即退出的常見原因之一，是監聽連接埠已被佔用。使用連接埠檢查指令找出程序編號後，再確認該程序屬於舊核心、其他代理工具還是正常系統服務。不要直接結束不明的系統程序；較安全的做法是關閉相關應用程式，或為用戶端選擇未使用的連接埠。若舊核心程序殘留，可先從用戶端執行停止，等待程序退出後再啟動。
TUN、寫入路由及某些系統級功能需要相應權限。一般代理模式可用但 TUN 啟動失敗時，應檢查權限提示、虛擬介面建立情況與系統安全策略。安裝目錄沒有寫入權限時，用戶端也可能無法儲存設定、日誌或解壓執行元件。請將程式放在目前使用者可讀寫的一般目錄，避免直接從壓縮檔內執行，也不要在多個目錄同時啟動同一份設定。
隔離訂閱資料、用戶端介面與核心
v2rayN 是 Windows、macOS 與 Linux 的桌面用戶端，v2rayNG 使用 Xray 核心，v2flyNG 使用 v2fly 核心。它們的介面、設定管理與核心實作並不在同一層。節點匯入成功但核心無法載入，可能是節點參數與目前核心能力不相容；核心可獨立執行但介面崩潰，則應重點檢查用戶端狀態檔、介面執行環境與系統日誌。
進行隔離測試時，可建立新的空白設定目錄，或使用用戶端提供的備份與還原功能，不應覆蓋唯一資料。先啟動不含訂閱與自訂路由的基礎環境，再逐步匯入一份已知設定。如果空白環境穩定、匯入後崩潰，問題集中在設定或資料；空白環境也崩潰，則更應檢查安裝檔、執行環境、權限與系統相容性。需要重新取得用戶端時，請從下載頁選擇與平台及架構相符的安裝套件。
處理日誌增長、休眠恢復與安全軟體攔截
長期啟用詳細日誌會增加磁碟寫入量與檔案大小。磁碟空間不足時，設定儲存、更新與日誌寫入都可能失敗。排查結束後，應將日誌層級恢復為日常設定，並依用戶端提供的方式清理舊日誌。不要在核心執行期間手動鎖定或移動正在寫入的日誌檔案，以免引發新的異常。
裝置從休眠恢復後，網卡位址、DNS 與預設路由可能改變，而核心仍持有恢復前的連線。此時先停止連線，等待系統網路穩定後再重新啟動核心，通常比直接重啟整台裝置更快。若每次休眠後都重現，應記錄恢復時的網卡、路由與日誌變化，確認是網路重建還是用戶端程序異常。
安全軟體可能阻止新下載的可執行檔監聽連接埠、建立虛擬介面或存取網路。應查看系統安全記錄是否明確攔截對應的用戶端與核心程序，並依實際路徑處理。不要長期關閉所有系統防護；透過事件記錄確認具體被攔截的對象，才能在保持其他規則不變的情況下恢復執行。
復原完成後應進行一次完整回歸測試：依序驗證用戶端啟動、連接埠監聽、節點連線、系統代理切換、訂閱更新與退出清理。只確認視窗能開啟，不足以說明故障已消失。若問題仍可穩定重現，請將最小重現步驟與處理過的日誌一併記錄，再查閱常見問題中的對應項目。
08 / ANDROID RUNTIME
Android 專項：授權、背景斷線與分應用程式代理
首次連線先確認系統授權
v2rayNG 與 v2flyNG 在 Android 上通常透過系統 VpnService 建立本機虛擬網路。首次連線時，系統會顯示授權提示，只有使用者確認後，用戶端才能接管相應流量。點擊連線後沒有狀態圖示、日誌立即回到未授權，或介面仍停留在未連線狀態時，應檢查授權是否已取消，以及系統中是否已有另一個使用相同類型介面的網路應用程式正在執行。
系統通常只允許一個此類連線同時處於啟用狀態。切換用戶端前，應先停止原本的連線，等待狀態圖示消失，再啟動 v2rayNG 或 v2flyNG。強制結束前一個應用程式但未正常中斷連線時，系統可能暫時保留舊介面；此時可進入系統網路設定中斷開舊連線，或重建網路後再試。不要同時讓多個應用程式輪流自動重連，否則可能出現連線剛建立就被另一個應用程式取代的情況。
背景斷線優先檢查電池與程序限制
鎖定螢幕後幾分鐘便斷線、切換至其他應用程式後停止傳輸、系統清理背景程序後無法自動恢復，通常與電池最佳化、背景活動限制或裝置製造商的程序管理有關。應將正在使用的用戶端加入系統允許背景執行的清單，允許必要的背景網路活動，並避免在工作清理介面中手動結束程序。不同 Android 系統的設定名稱可能不同，但判斷標準相同：鎖定螢幕後，用戶端程序與 VpnService 仍應保持執行。
只關閉一處電池最佳化不一定足夠。有些裝置同時提供應用程式耗電策略、自動啟動管理、背景資料、休眠應用程式與鎖定螢幕清理。應逐項確認，並在修改後鎖定螢幕一段時間進行實際請求，而不是只查看狀態列圖示。狀態圖示仍在但請求失敗時，還需檢查網路是否從無線切換至行動資料，以及核心是否成功重建連線。
Android 的省電模式可能延遲背景工作與網路存取。訂閱自動更新、連線保活與網路恢復都可能受影響。排查時先關閉系統省電模式進行比較；若問題消失，再針對用戶端調整單一應用程式策略，不必長期改變整台裝置的電量設定。更完整的操作說明請見v2rayNG 授權、省電與分應用程式代理。
處理無線網路與行動網路切換
從無線網路切換至行動網路時，本機 IP、預設路由與 DNS 都會改變，既有 TCP 連線通常無法繼續重用。用戶端應偵測網路變化並重新連線，但系統限制、訊號微弱或核心狀態可能造成恢復延遲。遇到切換後無法存取時，先等待系統網路本身恢復可用，再在用戶端中停止並重新連線，不要連續快速點擊開關。
若無線網路可用、行動網路失敗，請使用同一節點檢查目標連接埠可達性及 IPv4、IPv6 差異；反向情況則檢查路由器 DNS、區域網路篩選與無線網路登入狀態。公共無線網路通常要求先完成網頁登入，在建立虛擬網路前應先關閉用戶端完成接入驗證，再重新連線。只有某一種網路失敗時，不要重設訂閱或節點參數，因為相同設定已證明在另一個網路上可以運作。
分應用程式代理要明確區分「包含」與「排除」
分應用程式代理通常提供只代理所選應用程式，或略過所選應用程式兩種邏輯。兩者名稱相近，但結果相反。啟用前先確認目前模式，再檢查目標應用程式是否在清單中。若選擇「只代理」，未選取的瀏覽器與測試工具不會經過用戶端；若選擇「略過」，清單中的應用程式會直接使用原始網路。排查時可暫時關閉分應用程式規則，確認全域連線可用後，再逐一加入或排除應用程式。
應用程式更新或重新安裝後，其系統識別碼可能改變，舊規則不一定繼續匹配。若某個應用程式先前可用、更新後突然直連或斷網，應重新開啟分應用程式清單並儲存。系統元件、內嵌網頁與應用程式呼叫的外部瀏覽器可能屬於不同程序，只選取主應用程式不一定涵蓋完整登入流程。觀察核心存取日誌，可以確認請求是否真正進入用戶端。
Android DNS 與私有 DNS 的疊加關係
系統私有 DNS、用戶端核心 DNS 與應用程式自身解析可能同時存在。連線後只有網域失敗、直接 IP 請求有回應時，先檢查系統私有 DNS 目前是自動、關閉還是指定主機，再查看用戶端日誌中的 DNS 錯誤。指定的私有 DNS 主機若在目前網路上無法連線，會影響建立虛擬網路前後的解析。可暫時切換至系統自動模式進行比較，確認後再決定長期設定。
啟用本機 DNS 接管時，應確保查詢能透過目前出站完成，同時節點網域仍有可用的初始解析路徑。與桌面版相同，不能讓解析節點所需的 DNS 完全依賴尚未建立的節點。網路切換後若解析持續使用舊結果，可以停止連線，開啟再關閉飛航模式以重建網路，然後重新連線用戶端。此操作會中斷目前所有網路工作，應在儲存工作後執行。
應用程式能連線但無法存取時的最短流程
先關閉分應用程式代理，選擇一個已驗證的節點，確認系統授權存在；接著查看連線日誌是否完成節點握手，再用瀏覽器測試網域存取。若握手失敗，依節點逾時章節處理；握手成功但沒有任何存取日誌，表示應用程式流量沒有進入虛擬網路，應檢查授權與分應用程式設定；有存取日誌但 DNS 報錯，則處理系統私有 DNS 與核心 DNS；請求進入出站後逾時，則比較無線與行動網路。
若只有特定應用程式失敗，檢查該應用程式是否啟用獨立代理、私有 DNS、背景資料限制或僅限無線網路下載。清除整個用戶端資料會刪除訂閱與路由設定，不應作為第一步。較穩妥的方式是匯出或記錄現有設定，建立最小設定進行比較，再決定是否重設。v2rayNG 首選用於 Xray 核心設定，v2flyNG 可作為 v2fly 核心備選；切換用戶端測試時，應使用參數完整的同一節點，並注意兩者支援的核心能力可能不同。
| Android 現象 | 優先檢查 | 處理動作 |
|---|---|---|
| 點擊連線後立即停止 | 系統授權、設定載入日誌 | 重新授權並核對節點參數 |
| 鎖定螢幕後斷線 | 電池最佳化、背景活動 | 允許用戶端持續在背景執行 |
| 切換網路後失效 | 路由重建、DNS、節點可達性 | 確認基礎網路後重新連線 |
| 只有部分應用程式失敗 | 分應用程式模式、應用程式獨立設定 | 關閉篩選進行驗證，再逐項恢復 |
行動裝置問題往往由系統生命週期與網路切換共同觸發。穩定設定的標準不只是點亮連線狀態，還包括鎖定螢幕後保持連線、無線與行動網路切換後恢復，以及目標應用程式確實命中分流規則。每完成一項調整，都應執行對應情境測試，避免前景短暫成功後就結束排查。