V2Ray 設定檔完整參考

listen、port 與暴露範圍

入站物件首先需要確認的是 listen 與 port。桌面用戶端為本機應用程式提供代理時，通常監聽 127.0.0.1，表示只有目前裝置可以連線。將監聽位址改為涵蓋外部網路介面的位址，會改變入口的可達範圍，也需要同時考量本地網路邊界、系統防火牆與身分驗證。僅為瀏覽器、終端機或本機軟體提供代理時，沒有必要擴大監聽範圍。

連接埠必須未被其他程序占用。同一份設定中的兩個入站也不能在相同位址監聽同一個連接埠。常見用戶端會分別建立 SOCKS 與 HTTP 入站，或使用支援混合入口的實作。系統代理通常使用 HTTP 入口，而明確支援 SOCKS 的應用程式可以直接填寫 SOCKS 連接埠。應用程式把 HTTP 請求送到 SOCKS 連接埠時，日誌可能出現無法識別交握、連線關閉或請求格式錯誤；這類情況不是遠端節點故障，而是本機入口協定填寫錯誤。

SOCKS 入站與 UDP

{
  "tag": "socks-in",
  "listen": "127.0.0.1",
  "port": 10808,
  "protocol": "socks",
  "settings": {
    "auth": "noauth",
    "udp": true,
    "ip": "127.0.0.1"
  },
  "sniffing": {
    "enabled": true,
    "destOverride": ["http", "tls"],
    "routeOnly": true
  }
}

auth 控制 SOCKS 入口的驗證方式；僅監聽迴路位址時，經常使用 noauth。udp 決定是否接收 SOCKS UDP 請求。開啟這個選項不代表所有應用程式都會自動把 UDP 交給代理，應用程式本身還需要支援 SOCKS UDP，遠端協定與傳輸鏈也必須能處理對應流量。ip 用於 UDP 關聯返回位址時，應與實際可達方式相符。本機入口填寫迴路位址較直觀；如果入口面向其他裝置，則需要重新檢查該位址能否被請求方存取。

HTTP 入站與系統代理

{
  "tag": "http-in",
  "listen": "127.0.0.1",
  "port": 10809,
  "protocol": "http",
  "settings": {
    "allowTransparent": false
  },
  "sniffing": {
    "enabled": true,
    "destOverride": ["http", "tls"],
    "routeOnly": true
  }
}

HTTP 入站處理一般代理請求與 CONNECT 通道請求，適合瀏覽器及遵循系統代理設定的軟體。它與網站伺服器使用的 HTTP 服務並不是同一回事：應用程式必須明確知道這是代理連接埠。終端機指令、開發工具與背景服務不一定會讀取桌面系統代理，因此瀏覽器可以連線，並不能證明所有程式都會經過此入站。遇到「網頁正常但命令列直連」的情況，應先檢查目標程式的代理選項或環境變數，再檢查 V2Ray 設定。

sniffing 的作用與限制

流量探測用於從部分連線中還原目標網域，讓網域路由規則有機會生效。以 TLS 連線為例，應用程式可能先在本機完成網域解析，再向某個 IP 位址發起連線；如果入站只看到 IP，單純的網域規則可能無法比對。啟用 sniffing 後，核心可以從交握資訊辨識目標網域。destOverride 指定允許辨識的協定類型，routeOnly 表示辨識結果主要用於路由判斷，而不強制替換最終連線目標。

探測不是通用解密，也不能保證每條連線都有可辨識的網域。非標準協定、加密交握變化、應用程式自行封裝或直接存取 IP 時，都可能只保留 IP 條件。設定路由時應同時考量網域規則與 IP 規則，不要把所有判斷都寄託在探測結果上。若某個應用程式啟用探測後表現異常，可以對特定入站關閉探測，或拆分為獨立入站標籤，讓路由規則分別處理各個入口。

多個入站如何協作

多個入站最有價值的用途是區分流量來源。例如為瀏覽器保留 http-in，為開發工具保留 socks-in，再透過 inboundTag 為兩類入口設定不同路由。這比單純依網域猜測應用程式來源更穩定。每個入口都應有清楚的標籤，連接埠也應在用戶端介面、系統代理與應用程式設定之間保持一致。修改 v2rayN 的本機連接埠後，舊的系統代理值或終端機環境變數不一定會同步更新；排錯時要同時核對監聽日誌與應用程式端設定。

規則由上而下比對

routing.rules 是有順序的陣列。請求抵達路由器後，規則通常會由上而下檢查，第一個符合的規則決定目標出站。因此，範圍較小、意圖明確的規則應放在前面，涵蓋範圍大的規則放在後面。例如區域網路直連應位於廣泛代理規則之前，特定網域阻擋應位於通用網域代理規則之前。若把所有連接埠代理規則放在最前面，後面的區域網路直連規則就沒有機會生效。

規則的 type 通常使用 field，接著透過 domain、ip、port、network、protocol、inboundTag 等條件描述目標。一條規則同時包含多種條件時，必須滿足這些條件的組合才會命中；同一欄位中的多個值通常表示任一項符合。把彼此無關的條件塞進同一條規則，容易讓規則比預期更嚴格。更清楚的做法是拆成多條規則，並讓每條規則維持單一目的。

常用的基本分流結構

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "domainMatcher": "hybrid",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "protocol": ["bittorrent"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "domain:example.net",
          "full:status.example.org"
        ],
        "outboundTag": "proxy"
      }
    ]
  }
}

geoip:private 用於比對常見私有位址範圍，適合避免存取路由器、印表機與區域網路服務時繞經遠端。geosite:private 處理相應的私有網域集合。GeoIP 與 GeoSite 是不同的資料來源：前者依 IP 範圍分類，後者依網域集合分類。資料檔過舊可能導致分類結果落後，更新方法可參閱GeoIP 與 GeoSite 資料檔更新方法。

domain: 比對指定網域及其子網域，full: 只比對完整主機名稱，keyword: 依關鍵字比對。精確服務應優先使用 full:，整個網站及其子網域則可使用 domain:。關鍵字範圍較寬，容易意外命中名稱相似但無關的網域，適合範圍明確且經日誌驗證的情境。規則中的一般字串在不同核心設定語境下可能有不同預設解讀，手寫設定時使用前綴可減少歧義。

domainStrategy 如何影響網域與 IP 規則

AsIs 表示路由階段盡量依原始目標處理。請求以網域進入時，網域規則可以參與比對；請求只有 IP 時，網域規則通常無法憑空還原名稱。IPIfNonMatch 表示網域規則未命中時，再解析網域並嘗試套用 IP 規則。IPOnDemand 則可能在遇到需要 IP 的規則時更早觸發解析。不同策略會影響 DNS 查詢時機、路由命中與連線耗時，不應只依名稱選擇。

如果希望優先使用網域集合、以 IP 地理規則作為補充，IPIfNonMatch 通常較容易理解：先檢查網域，未命中時解析並繼續檢查 IP。若設定了大量 IP 規則且需要盡早取得位址，可以評估 IPOnDemand。若完全不希望路由器為比對規則主動解析，則使用 AsIs，同時確保入站探測或應用程式請求能提供足夠的目標資訊。

依連接埠、網路與入站標籤分流

{
  "type": "field",
  "inboundTag": ["socks-in"],
  "network": "tcp",
  "port": "443",
  "outboundTag": "proxy"
}

連接埠可以寫單一值或範圍，例如 80,443、10000-20000。連接埠只描述目標服務的連接埠，不能代表特定網站或應用程式；大量服務共用 443 連接埠，因此只依連接埠分流通常範圍很大。network 可用於區分 TCP 與 UDP，inboundTag 則依請求進入的本機入口分流。為不同軟體建立獨立入口，再使用入站標籤處理，往往比猜測程序名稱更通用。

規則未命中與錯誤命中

沒有規則命中時，請求會使用預設出站。預設行為必須透過設定結構與核心實作確認，不要假設一定直連或一定代理。排錯時先開啟適當等級的執行日誌，記錄請求目標、入站標籤與最終出站標籤。若規則未命中，檢查請求帶的是網域還是 IP、網域探測是否生效、Geo 資料是否存在，以及規則前綴是否正確。若錯誤命中，則從陣列頂端往下尋找第一條能涵蓋該目標的規則。

調整路由後，應使用少量明確目標分別驗證：一個區域網路位址、一個預計直連的網域、一個預計代理的網域，以及一個阻擋目標。不要以「大多數網頁都能開啟」作為分流正確的依據，因為預設出口可能掩蓋規則錯誤。節點測速也只能說明特定測試請求的連線結果，不能取代逐條驗證。有關系統代理與終端機走向不同的問題，可繼續閱讀瀏覽器與命令列終端機分開排查。

levels 與使用者等級引用

policy.levels 以使用者等級為鍵，為對應等級的連線設定策略。部分入站或出站協定的使用者物件可以帶有 level，執行時會查找同名策略。等級不是速度評分，也不是權限高低的自動排序；它只是一個用來引用策略集合的數字鍵。若使用者沒有明確設定等級，通常會使用預設等級，但具體預設行為仍應配合目前設定與核心實作確認。

同一等級可以統一控制交握時間、連線閒置時間、上下載統計等項目。不要為了「看起來完整」而建立大量未被引用的等級。對於用戶端產生的單一使用者出站，通常只需了解預設等級是否啟用了統計或修改了逾時。伺服器多使用者情境會更常使用等級區分，但本頁重點是用戶端設定閱讀，因此更應留意策略是否意外縮短正常連線。

策略物件範例

{
  "policy": {
    "levels": {
      "0": {
        "handshake": 4,
        "connIdle": 300,
        "uplinkOnly": 2,
        "downlinkOnly": 5,
        "statsUserUplink": false,
        "statsUserDownlink": false,
        "bufferSize": 4
      }
    },
    "system": {
      "statsInboundUplink": true,
      "statsInboundDownlink": true,
      "statsOutboundUplink": true,
      "statsOutboundDownlink": true
    }
  },
  "stats": {}
}

handshake 用於限制建立連線階段的等待時間。設定過短時，網路波動、名稱解析或遠端交握稍慢就可能被提前終止；設定過長則會讓無法到達的連線更久才回報失敗。connIdle 描述連線在沒有資料傳輸時可以維持的時間。長連線應用程式、訊息推播、遠端終端機與持續傳輸工具對閒置時間更敏感，不能只依網頁瀏覽體驗調整。

uplinkOnly 與 downlinkOnly 處理只剩單向資料後的連線保留時間。它們用於連線生命週期管理，不代表頻寬限制。bufferSize 會影響每條連線的資料緩衝策略，盲目增大可能提高記憶體使用量，盲目減小也可能影響吞吐量。大多數用戶端使用者應保留核心或用戶端提供的預設值，只有在日誌與可重現測試顯示問題和連線生命週期有關時才進行調整。

統計開關需要成對理解

statsUserUplink 與 statsUserDownlink 控制使用者維度的統計，policy.system 中的項目則控制入站與出站維度的統計。僅寫入 "stats": {} 不一定會自動收集所有指標；對應的 policy 開關也需要啟用。反過來，啟用統計但沒有任何介面或 API 讀取這些值，只會產生額外的記錄工作。桌面用戶端是否顯示流量統計，也取決於它如何啟動核心與讀取統計介面。

統計值適合觀察目前執行個體中的流量方向，不應被視為訂閱額度、計費記錄或遠端伺服器流量的權威來源。用戶端重新啟動、設定重新載入與核心切換，都可能讓本地統計重新開始。排查「介面沒有流量數字」時，先確認用戶端是否設計為讀取底層統計，再檢查 stats 物件與 system 開關，不要直接修改協定參數。

policy 與逾時錯誤的關係

日誌中的 timeout 可能發生在名稱解析、TCP 連線、TLS 或 REALITY 交握、代理協定交握、業務讀寫等不同階段。policy 只能解釋其中一部分工作階段逾時。若連線在固定且很短的時間後中斷，可以檢查 handshake 與 connIdle；若日誌明確指出連線至遠端位址逾時，應先檢查網路與出站；若只有某個應用程式的長連線定期中斷，則比較其閒置週期與策略值。

修改逾時前，應先記錄錯誤發生階段與時間規律。簡單地把所有值調得很大，會延遲故障回報，也會讓失效連線長時間占用資源。全部調小則會損害慢速網路與長連線。合理做法是保留預設策略作為基準，只對可重現的情境進行單項調整，並在用戶端重新啟動後重新測試同一目標。

系統策略與設定可攜性

不同用戶端與核心家族可能支援不同的策略欄位或預設值。v2rayN 使用的執行核心、v2rayNG 常見的 Xray 核心，以及 v2flyNG 對應的 v2fly 核心，在相容欄位之外仍可能存在行為差異。將一份完整設定複製到另一個用戶端前，應先檢查目標用戶端是否允許完整自訂設定，以及它是否會在啟動時重寫 policy。

設定可攜性的核心不是欄位越少越好，而是清楚區分標準結構、核心擴充與用戶端產生的內容。入站連接埠、日誌路徑、TUN 參數等通常與平台環境有關；伺服器協定參數通常可以移轉；用戶端介面狀態與執行設定則不一定一一對應。跨平台移轉時，先匯入訂閱建立可運作基準，再逐項移轉路由、DNS 與策略，比直接覆蓋整份檔案更容易發現不相容欄位。

啟動失敗：先檢查語法、連接埠與引用

核心啟動後立即退出，通常應先檢查三類問題。第一類是 JSON 語法錯誤，包括缺少逗號、括號不相符與資料型別錯誤；第二類是本機資源衝突，例如監聽連接埠已被另一個程序占用、日誌目錄無法寫入，或 TUN 裝置無法建立；第三類是設定物件引用錯誤，例如路由目標標籤不存在、協定設定缺少必要欄位，或目前核心不認識某個擴充項目。

處理順序應與日誌一致。解析錯誤發生在讀取階段，先修復檔案；位址占用發生在監聽階段，檢查重複用戶端與本機連接埠；找不到出站發生在建立路由階段，核對標籤；只有核心明確進入執行狀態後，才進入遠端連線排查。看到用戶端介面顯示「未連線」不足以判斷是哪一層，必須查看最後一段錯誤日誌。

本機連接埠存在，但應用程式沒有流量

先確認應用程式填寫的是正確的代理類型與連接埠。HTTP 代理與 SOCKS 代理不是同一個入口，系統代理也不保證終端機與背景服務會自動使用。接著檢查應用程式是否繞過本機位址、是否啟用了自己的解析或代理設定，以及請求是否實際抵達 access 日誌。日誌完全沒有這次請求，表示問題位於應用程式到入站之間；日誌出現入站記錄後，才表示流量已進入 V2Ray。

如果只有部分應用程式無法運作，可以為問題應用程式設定明確的 SOCKS 或 HTTP 入口作為對照。手動入口可用而系統代理不可用時，檢查作業系統代理狀態與排除清單；系統代理下瀏覽器可用而終端機不可用時，為終端機工具設定它支援的代理選項。不要因為某個應用程式繞過系統代理，就修改遠端節點協定。

網域失敗但 IP 可用

這種現象應優先檢查解析路徑。確認應用程式提交的是網域還是已解析的 IP、內建 DNS 是否收到查詢、伺服器是否返回可用位址，以及 queryStrategy 是否選擇了目前網路可達的位址族。若網域規則依賴探測，還要檢查入站是否能辨識目標名稱。使用 Fake DNS 時，檢查保留位址是否由同一個執行個體還原。

如果 DNS 已經返回位址，但連線在出站階段逾時，問題就不再是「沒有解析結果」，而是該位址的連線路徑、路由或遠端服務。若返回位址被 expectIPs 判定為不符合預期，請檢查 Geo 資料與伺服器分組。若只有剛修改的網域仍使用舊位址，應考慮應用程式、系統與內建快取，並透過重新啟動相關程序或測試新網域排除快取影響。

規則看似正確卻沒有命中

先從請求的實際形式檢查：路由器取得的是完整網域、子網域還是 IP；規則使用的是 full:、domain: 還是關鍵字；前面是否存在更寬泛的規則提前命中；Geo 資料檔是否可用。規則文字與目標看似相近，不代表比對語義相同。full:example.com 不會比對其他子網域，而過於寬泛的關鍵字可能會命中多個無關目標。

將問題規則暫時移到陣列較前的位置，可以用來判斷是否被其他規則遮蔽，但測試結束後仍要重新檢視整體順序。更可靠的方法是啟用路由相關日誌，記錄請求最後選擇的出站標籤。若請求只有 IP，網域規則自然不會命中；此時應檢查 sniffing、應用程式解析方式，或補充合理的 IP 規則，而不要不斷改寫同一個網域字串。

節點參數正確但交握失敗

先確認伺服器位址與連接埠可達，再核對協定身分參數、傳輸方式與安全層。TLS 情境檢查伺服器名稱、系統時間與憑證錯誤；REALITY 情境檢查伺服器名稱、公鑰、短識別碼、指紋與流控參數；其他協定同樣要確保用戶端參數與伺服器逐項對應。不要把不同節點的傳輸欄位拼成一份設定，因為每一層都可能有依賴關係。

如果訂閱更新後突然失敗，可保留舊節點作為對照，檢查更新是否改變了位址、連接埠、傳輸方式或身分參數。不要手動猜測缺少的欄位。若所有節點同時失敗，應優先檢查本機網路、系統時間、核心啟動與路由；只有單一節點失敗時，才較可能集中在該節點參數或遠端狀態。

設定逐漸膨脹後的整理原則

長期使用後，設定中容易累積失效標籤、重複網域規則、彼此覆蓋的 Geo 規則與不再使用的入站。整理時先繪製目前的處理鏈：列出所有入站標籤、所有出站標籤、每條規則的目標與 DNS 伺服器用途。確認沒有引用後再刪除物件。相同目標與相同出口的規則可以合併，但不要為了減少行數而把不同目的的條件塞進一條難以解釋的規則。

建議為標籤建立穩定的命名規則，並依「特殊阻擋、區域網路直連、特定代理、預設處理」的邏輯排列路由。DNS 伺服器物件依適用網域範圍分組，policy 只保留實際使用的等級。設定檔本身不支援註解時，可以在獨立的維護記錄中寫明每個標籤的用途、最後一次驗證情境與用戶端產生方式，避免之後看到欄位卻不敢調整。

用戶端更新與設定移轉

更新用戶端前，儲存目前可運作的設定、路由預設與訂閱設定。更新後先使用原有節點完成最小連線測試，再檢查進階功能。若用戶端切換了執行核心，請留意啟動日誌中的未知欄位與棄用提示。不要因為介面選項名稱改變，就立即刪除底層設定；先匯出新產生的執行檔案，再與舊設定按頂層區段比較。

從桌面端移轉到另一個桌面平台時，伺服器協定參數通常可以透過訂閱復原，但本機監聽連接埠、系統代理、TUN 權限與日誌路徑需要依新平台重新設定。從 Android 移轉到 v2rayNG 或 v2flyNG 時，同樣應先匯入訂閱，再依目標核心復原路由與 DNS。平台差異主要在系統接管與檔案位置，不應在伺服器出站中加入與平台無關的猜測欄位。

建立固定的排錯清單

每次故障都依這四層順序記錄，可以避免重複勞動。日誌出現 rejected 時，查看拒絕發生在本機入口、路由阻擋還是遠端；出現 timeout 時，確認逾時階段；出現身分或交握錯誤時，回到對應的出站參數。若仍無法判斷，可前往疑難解答，依基礎認知、安裝設定、使用技巧與故障排查分類繼續查找。

設定維護的目標不是堆滿可選欄位，而是讓每個區段都有明確作用，並能透過日誌證明處理結果。先保留一份結構簡單、可重複驗證的基準，再增加路由、DNS、TUN 與策略。遇到問題時回到基準逐層恢復，比從複雜設定中隨機刪除欄位更可靠。