系統代理、全域模式與繞過中國大陸模式詳解：三種模式如何選擇

系統代理、全域模式和繞過中國大陸模式經常出現在同一個用戶端介面中，但三者並不屬於同一層級。系統代理決定應用程式是否將連線交給本機代理連接埠，後兩者則主要決定這些連線進入 V2Ray 或 Xray 核心後，應從哪個出站連線。將「流量入口」與「核心路由」分開理解，是排查網頁無法開啟、中國大陸網站變慢，以及部分程式未經代理的基礎。

先區分兩個控制層：系統代理負責入口，路由模式負責出口

在桌面系統中，v2rayN 啟動核心後會監聽本機連接埠。以常見設定為例，SOCKS 入口位於 127.0.0.1:10808，HTTP 入口位於 127.0.0.1:10809。實際連接埠應在 v2rayN 的「設定」→「參數設定」中確認，因為舊設定遷移、連接埠衝突或使用者修改都可能改變數值。

啟用系統代理後，用戶端會將作業系統的代理位址指向這些本機連接埠。瀏覽器及遵循系統代理設定的桌面程式會隨即把請求交給 v2rayN。關閉系統代理只會撤銷作業系統中的入口指向，不代表核心停止，也不一定會終止已建立的連線。手動填寫 SOCKS 位址的程式仍可繼續使用本機代理。

因此，「啟用系統代理並使用繞過中國大陸」是一組完整的搭配，而不是兩個互斥選項。前者會將支援系統代理的流量送進核心，後者再依據網域、IP、連接埠或入口標籤選擇 direct、proxy 或 block 等出站。

• 應用程式層：程式是否讀取系統代理，或是否手動指定 127.0.0.1 的代理連接埠。
• 入口層：HTTP、SOCKS 或透明代理入口是否正常監聽，連接埠是否被其他程式佔用。
• 路由層：網域、IP、協定與連接埠規則依照什麼順序比對。
• 出站層：命中規則後，使用代理節點、直接連線，還是阻斷連線。

系統代理的作用範圍：為什麼有些程式仍會直連

系統代理並不是桌面系統中的全裝置流量接管機制。多數瀏覽器會讀取系統設定，但部分下載器、命令列工具、遊戲啟動器及自行實作網路堆疊的程式可能會忽略它。此時，即使 v2rayN 系統匣圖示顯示系統代理已啟用，該程式仍可能直接連線至目標位址。

判斷程式是否進入代理鏈路，不能只看節點延遲。更可靠的方法是同時查看核心日誌、程式本身的代理設定及出口位址。以命令列工具為例，可以明確指定 HTTP 代理進行一次對照請求；若指定代理時日誌出現新連線，而未指定時沒有記錄，就表示該工具預設未採用系統代理。

curl --proxy http://127.0.0.1:10809 https://api.ipify.org
curl https://api.ipify.org

兩次請求可以形成最小化對照：第一條明確經過本機 HTTP 入口，第二條使用命令列工具的預設網路設定。出口位址是否不同，取決於節點、目前路由與本機網路；但核心日誌是否出現對應連線，可以直接說明請求是否進入 v2rayN。測試結束後不需要修改訂閱或節點參數。

在 Android 端，v2rayNG 和 v2flyNG 通常透過系統提供的 VPN 服務接收流量，概念上不同於桌面系統代理。v2rayNG 使用 Xray 核心，v2flyNG 使用 v2fly 核心；兩者都能在流量進入核心後繼續執行路由規則。若啟用了分應用程式代理，還要先確認目標應用程式是否位於選定範圍內。

全域模式的真正含義：全域路由不等於所有流量都會被接管

全域模式通常表示已進入核心的流量主要使用代理出站。它適合暫時驗證節點連線能力：如果在繞過中國大陸模式下某個網域無法開啟，切換全域後恢復，問題更可能出在網域分類、DNS 結果或規則順序，而不是節點本身。

全域模式仍有其界線

「全域」描述的是目前的路由策略，不會自動改變所有應用程式的網路實作。忽略系統代理的桌面程式仍可能直連；僅監聽本機 HTTP 或 SOCKS 入口的用戶端，也無法透過路由預設值捕獲尚未進入入口的連線。區域網路裝置的流量同樣不會因本機切換全域模式，就自動經過代理。

• 本機回送位址與區域網路位址通常需要維持直連，避免印表機、路由器管理頁面或本地開發服務失去連線。
• 節點伺服器本身的連線必須避免再次送回同一個代理出站，否則可能形成迴圈。
• DNS 查詢可能分別由系統、核心或應用程式發起，路由模式名稱本身無法單獨說明 DNS 的實際出口。
• 已建立的長連線可能不會立即採用新規則，切換後應重新開啟目標程式或重新建立連線。

何時適合短時間使用全域模式

當訂閱更新後只有部分網站異常、某條自訂規則疑似誤判，或需要確認 VMess、VLESS 節點本身能否建立連線時，全域模式可作為對照組。它能減少規則分支，但不會修復節點參數、系統時間、傳輸層設定或連接埠衝突。若全域模式下仍然失敗，應回到日誌檢查握手、DNS 與連線逾時資訊。

1. 選擇一個狀態正常的節點，並確認核心已啟動。
2. 啟用系統代理，或確認目標應用程式已手動指定本機代理。
3. 切換至全域路由，關閉目標頁面後重新開啟。
4. 記錄日誌中的目標網域、命中出站與錯誤類型。
5. 恢復原有路由模式，再執行一次相同請求作為對照。

繞過中國大陸模式如何運作：網域規則、IP 規則與比對順序

繞過中國大陸模式通常透過網域分類與 IP 地理資料進行分流。中國大陸常用網域、解析至中國大陸網段的位址，以及私有網路位址會進入直連出站，其餘流量則進入代理出站。不同用戶端版本、路由資料版本及訂閱附帶設定可能有所差異，因此模式名稱相同，不代表規則內容逐條一致。

1. 先取得目標資訊：核心會從連線中取得網域、目標 IP、連接埠、網路類型與入口標籤。
2. 依陣列順序檢查：路由規則通常由上而下進行比對，命中後採用指定出站，不再繼續檢查後面的普通規則。
3. 處理網域與解析結果：部分策略直接依據網域分類，部分規則還會根據解析取得的 IP 再判斷地區。
4. 進入兜底出站：未命中前置規則的連線，會依預設規則進入代理或直連。

例如，某個中國大陸服務使用境外 CDN，或某個境外服務將靜態資源部署在中國大陸節點，單靠 IP 地區判斷可能得到與使用者預期不同的出口。網域規則通常更適合表達「這項服務應該走哪條線路」，IP 規則則適合作為無網域連線與解析結果的補充。遇到分流錯誤時，應先在日誌中確認核心取得的是網域還是純 IP。

DNS 也會影響判斷。應用程式自行進行加密解析、核心接管網域解析，以及系統 DNS 回傳不同位址時，同一個網域可能命中不同的 IP 規則。排查時不應同時大幅修改 DNS、節點與路由，否則很難確定是哪一項造成變化。較穩妥的方法是每次只變更一個變數，並重新建立連線。

依使用情境選擇：日常、開發、下載與行動網路

對多數桌面日常使用而言，合理的起點是啟用系統代理並選擇繞過中國大陸模式。中國大陸服務維持較短的直連路徑，其餘流量則依規則進入代理。只有在規則誤判、需要統一出口或進行故障對照時，才暫時切換至全域模式。

開發環境通常需要額外處理套件管理器、容器、虛擬機器與本地回呼位址。瀏覽器採用系統代理，不代表終端機、容器內部或虛擬機器會自動繼承相同設定。應分別核對各環境的 HTTP、HTTPS 或 SOCKS 代理變數，並為內網套件庫、本地介面與回送網段設定直連。

• 日常瀏覽：啟用系統代理，將繞過中國大陸作為常用路由，遇到單一網站異常時再新增精確的網域規則。
• 規則排障：暫時使用全域模式完成對照，保留日誌後再恢復原有路由。
• 下載工具：優先檢查工具本身的代理選單，不要只憑系統代理圖示判斷。
• 本地開發：明確將 localhost、回送位址與實際區域網路網段設為直連，避免回呼請求繞道。
• Android 裝置：檢查 VPN 連線、路由預設值與分應用程式範圍三個層面，而不是套用桌面系統代理的概念。

切換模式前後的標準檢查流程

穩定的排查流程應先驗證入口，再驗證路由，最後檢查節點。直接在多個節點、DNS 設定與模式之間反覆切換，會讓日誌失去對照價值。以下順序適用於 v2rayN，也能對應到 v2rayNG 的 VPN、路由與核心日誌介面。

1. 確認核心狀態：啟動用戶端後查看日誌，確認本機監聽成功，且沒有 address already in use 這類連接埠佔用錯誤。
2. 確認流量入口：桌面端檢查系統代理或應用程式內的代理設定；Android 端檢查 VPN 服務與分應用程式範圍。
3. 固定測試節點：整個對照過程只使用一個節點，避免節點差異干擾結論。
4. 分別測試兩種路由：先使用繞過中國大陸，再切換至全域，每次都重新建立目標連線。
5. 讀取命中結果：記錄目標網域、目標 IP、出站標籤與錯誤類型，不要只看介面上的延遲。
6. 進行最小修改：確認是分流錯誤後，只新增一條精確規則；確認是入口問題後，只調整應用程式的代理設定。

如果某個程式始終不受模式切換影響，應優先檢查它是否進入核心；如果同一程式在全域模式正常、繞過中國大陸模式異常，再檢查規則分類與 DNS；如果兩種模式都失敗，則回頭檢查節點參數、網路可達性、系統時間與核心日誌。依照這個順序判斷，能避免將入口問題誤認為路由問題。