V2Ray 設定檔參考

01 / STRUCTURE

JSON 結構與設定範圍

設定檔先描述各物件之間的關係，再由核心將物件串接成處理流程。應用程式將請求交給入站，路由檢查目標與來源條件，最後選擇出站建立連線。DNS 可參與網域解析，策略用來限制連線資源，日誌則記錄執行狀況。這些部分不是依序執行的指令區塊，調整它們在檔案中的排列位置，通常不會改變處理順序；但陣列內的項目順序可能直接影響結果。

先確認實際載入的設定檔

v2rayN 等圖形化用戶端通常會依據節點、路由及 DNS 介面產生執行設定。介面中的訂閱群組、視窗配置與測速設定屬於用戶端資料，不是核心的頂層欄位。即使磁碟上有名為 config.json 的檔案，也不能因此認定它就是目前執行中的設定檔。請透過用戶端的執行資訊、設定檢視入口或啟動日誌，確認核心類型與設定來源，再決定要在哪裡修改。

手動修改自動產生的檔案，往往只會影響單次執行。切換節點、更新訂閱、儲存設定或重新啟動核心時，用戶端可能會重新產生檔案並覆蓋修改內容。日常維護建議優先使用介面提供的路由、DNS 與自訂設定入口。若確實需要完整自訂設定，請先確認該模式是否仍會套用用戶端產生的規則，避免誤以為兩份設定會自動合併。

從可獨立執行的最小設定開始

以下完整基準設定會在本機迴圈位址上監聽 SOCKS 連接埠，並將所有流量直接連往目標。它可用來檢查核心能否載入設定、本機連接埠是否可連線，以及標籤是否設定正確。若連接埠已被使用，請改用未占用的連接埠。此範例不會建立遠端代理連線，測試時的網路路徑仍是裝置本身的直連路徑。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "inboundTag": ["local-socks"],
        "outboundTag": "direct"
      }
    ]
  }
}

以這個結構為基礎擴充時，每次只新增一項功能。先新增一個帶有獨立標籤的出站，再新增引用該標籤的規則，接著確認規則是否命中；不要同時更換 DNS、啟用嗅探、調整策略及修改預設出站。最小基準設定的目的不是提供完整功能，而是保留可回復的狀態，讓每次變更都有清楚的因果關係。

物件、陣列與欄位型別

inbounds 與 outbounds 是陣列，可分別放入多個物件；routing、dns、policy 與 log 則是物件。字串必須使用英文雙引號，布林值寫成 true 或 false，數字與字串也應依欄位要求區分。有些連接埠範圍欄位接受字串，不代表所有連接埠欄位都能混用型別。

為確保不同工具都能讀取，本頁範例採用嚴格 JSON：不含註解、尾隨逗號或重複鍵。有些載入器允許擴充語法，但編輯器能開啟，不代表目前的核心也能載入。尤其要避免將說明文字貼到引號外，或從文件複製中文引號。錯誤位置通常指出問題被發現之處，真正缺少的逗號可能在上一行。

這六個常見欄位並非所有頂層欄位。統計、管理介面及其他擴充模組可能需要額外設定；不要為了讓結構看起來完整，就照本宣科地加入空模組。查閱時應先判斷問題屬於接收、比對、解析還是連線，再查看對應章節。這比逐一嘗試網路上找到的參數，更容易維持正確的設定範圍。

02 / INBOUNDS

inbounds 入站設定

入站定義核心從哪裡接收流量，以及如何解讀收到的資料。本機應用程式使用 SOCKS 或 HTTP 代理時，連線對象是代理入站，而不是遠端節點位址。入站可用只代表應用程式能連上核心，不能證明遠端出站連線成功。排查時先將本機接收與遠端連線分開，能避免把連接埠問題誤判為節點問題。

監聽位址與連接埠

listen 決定監聽的網路介面，port 則指定本機服務的連接埠。僅供本機程式使用時，明確設定為 127.0.0.1 可縮小接收範圍。若改為允許所有介面存取的位址，區域網路中的其他裝置也可能連上該連接埠，必須一併考量系統防火牆、可存取範圍與驗證設定。開放監聽並不足以確保分享成功，也不應在連線失敗時當成預設的修正方式。

兩個入站不能在相同位址與連接埠上重複監聽相同傳輸方式。占用連接埠的可能是另一個用戶端執行個體，也可能是上次未正常結束的核心程序。若綁定失敗，請先結束重複執行的執行個體，再確認連接埠是否恢復可用。直接更換連接埠後，也必須同步修改瀏覽器、系統代理或其他應用程式的代理位址，否則應用程式仍會連到舊連接埠。

SOCKS 與 HTTP 不能互換

以下是可合併至頂層的 inbounds 欄位片段。兩個入口使用不同連接埠，並以標籤區分來源。SOCKS 的 UDP 開關只表示該入口允許相應請求，不代表所有應用程式、所有出站及整條網路路徑都支援 UDP。HTTP 入口主要供使用 HTTP 代理協定的應用程式使用，不能因為連接埠可連線，就把它當成 SOCKS 使用。

{
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    },
    {
      "tag": "local-http",
      "listen": "127.0.0.1",
      "port": 10809,
      "protocol": "http",
      "settings": {}
    }
  ]
}

應用程式中的代理類型必須與入口協定相符。將 HTTP 請求直接送到 SOCKS 連接埠，可能會遭到中斷、收到協定錯誤或沒有回應；此時更換節點無法解決問題。也要確認應用程式是將目標網域交給代理，還是先自行解析再提交 IP。這兩種方式會影響核心可見的目標資訊，進而影響後續網域規則的比對。

標籤與來源辨識

tag 是設定內部使用的名稱，不是網路位址，也不會決定監聽行為。建議使用穩定、簡短且語意明確的標籤，例如分別命名本機 SOCKS 與本機 HTTP。路由中的 inboundTag 必須逐字引用標籤，包含大小寫。修改標籤後若漏改規則，原本針對該入口的規則就會失效，流量可能改為比對後續規則或使用預設出站。

使用獨立標籤可區分不同應用程式入口。例如保留一般入口，再新增一個專供測試的入口，透過入站標籤將測試流量送往指定出站。如此一來，不必反覆修改所有應用程式的全域規則，也能驗證新的出口。不過入口愈多，連接埠與規則的關係也愈複雜；暫時不使用的入口應刪除或停用，避免長期設定中留下過期的測試路徑。

嗅探可以補充哪些資訊

有些請求進入核心時只帶有 IP，嗅探可嘗試從受支援協定的初始資料中擷取網域資訊，例如 HTTP 主機名稱或部分 TLS 握手中的伺服器名稱。它不是解密工具，也無法保證辨識所有加密流量。目標應用程式的協定、握手形式及隱私特性都會影響資訊的可見程度，因此啟用嗅探不代表所有網域規則都會命中。

{
  "sniffing": {
    "enabled": true,
    "destOverride": ["http", "tls"]
  }
}

以上是放入單一入站物件的欄位片段，不是頂層物件。destOverride 涉及依嗅探結果修正目標的行為，具體支援項目與選項請依核心確認。若只想讓嗅探結果參與路由比對，而不改寫連線目標，請確認目前的核心是否提供專用路由選項。不要照抄另一種核心的擴充欄位，並假定兩者行為相同。

驗證入站時，先確認用戶端日誌沒有監聽錯誤，再讓明確支援代理設定的應用程式使用該入口。若核心完全沒有收到請求，請優先檢查應用程式設定與接管範圍；若已有接收紀錄，再查看路由與出站章節。Android 的網路接管也受到系統授權與每個應用程式的設定影響，其介面入口與桌面系統代理不同。

03 / OUTBOUNDS

outbounds 出站設定

出站描述核心如何連線至目標，可以直接連線、交由遠端代理轉送，或依規則拒絕請求。入站負責接收，出站負責傳送，兩者透過路由相連。遠端節點無法使用時，本機入站仍可能正常監聽；用戶端介面顯示節點名稱，也不代表目前的核心已接受其出站參數。設定檔成功產生與連線成功，必須分開驗證。

預設出口由排列順序決定

在傳統設定中，未被路由規則選中的流量，通常會交由 outbounds 陣列中的第一個出站處理。這項預設行為非常重要：只要對調兩個物件的位置，就可能改變所有未命中請求的路徑。不能只看標籤名稱是 direct 或 proxy 就推斷預設出口；名稱只供引用，實際行為取決於協定、設定與排列位置。

以下欄位片段將直連出站放在第一項，並另提供拒絕出口。它適合說明本機基準設定與規則引用的關係，不包含遠端節點。若實際需求是讓未命中的請求使用遠端代理，就必須重新規劃第一項或末尾的兜底規則，同時確認網域解析、訂閱更新與本機網路存取是否也會一併送往該出口。

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

直連、拒絕與遠端協定

freedom 是直接連線至目標的出站協定。直連仍受本機網路、防火牆與目標服務狀態限制，不能因為繞過遠端節點，就認定一定連得上。blackhole 用於拒絕或丟棄符合條件的流量，適合明確的封鎖規則；應用程式端可能出現失敗、無回應或持續等待，實際情況取決於協定與回應設定。排查時應先確認流量是否被送入拒絕出口。

遠端代理出站還需要伺服器位址、連接埠、身分資訊，以及傳輸與安全參數。VMess、VLESS、Trojan 和 Shadowsocks 的設定物件並不通用，不能只替換 protocol 就將一種節點轉換成另一種。請使用可信的節點資料或用戶端匯入功能產生相應欄位，再檢查產生的設定；不要在不完整的網路片段中逐項猜測設定值。

節點位址是實際連線的伺服器；TLS 伺服器名稱則用於握手驗證或相關協定行為，兩者不一定相同，但都必須符合伺服器端的設定。傳輸層路徑、主機名稱與安全層伺服器名稱也各有不同用途。遇到握手失敗時，應逐層核對，不要把三個欄位都改成伺服器 IP。停用憑證驗證會掩蓋問題，不適合作為一般疑難排解步驟。

先確認核心支援範圍，再組合欄位

Xray 與 V2Fly 共用部分沿用至今的設定概念，但不保證擴充協定與傳輸選項都能互通。節點需要 REALITY 或特定流控欄位時，應先確認用戶端實際啟動的核心能否處理。v2rayNG 與 v2flyNG 採用的核心方向不同；桌面端使用 v2rayN 時，也應以目前的節點與執行資訊為準，不要只憑用戶端名稱推斷所有功能都受支援。

協定、傳輸與安全層彼此相關，但屬於不同層面。VLESS 是代理協定，TLS 或 REALITY 屬於安全相關設定，實際網路傳輸也有自己的參數。若將功能寫在錯誤的層級，可能直接造成設定錯誤，也可能在載入後出現協商失敗。相關背景可參閱REALITY 與 XTLS Vision 原理說明；實際欄位仍應以所用核心為準。

再次檢查標籤與連線路徑

每個需要由規則引用的出站都應設定唯一標籤。重複標籤會讓設定難以判讀，也不應依賴工具對重複值的處理方式。重新命名出站後，請同步檢查路由、可能存在的出口鏈及其他引用位置。只修改介面中的節點顯示名稱，不一定會改變產生的設定檔裡的出站標籤；因此檢視實際執行設定，比只看節點清單名稱更可靠。

診斷出站時，可先用本機直連基準設定測試目標服務，再使用相同入口與相同測試目標切換至遠端出口。若只有遠端路徑失敗，請進一步檢查伺服器位址解析、連接埠連通性、安全握手及驗證參數。不同目標可能套用不同路由，不能因一次網頁連線成功就認定所有出口都正常，也不能只憑一個目標逾時就判定整個節點完全無法使用。

維護時，應清楚界定預設出口、明確直連、明確拒絕與遠端出口的用途。新增出口後先單獨驗證，再讓少數規則引用，最後才考慮變更預設路徑。依照這個順序，可以避免新節點設定錯誤影響所有請求；發生問題時也能只回復相關規則，不必重建整份設定。

04 / ROUTING

routing 路由規則與順序

路由會將請求條件對應至出站標籤。理解路由的關鍵不在規則數量，而在比對順序、條件組合及目標資訊是否可見。傳統欄位規則通常由上往下檢查，首次符合條件後就會選定出口，不會自動繼續尋找更具體的規則。因此，精確例外通常應放在較寬泛的規則前面，兜底規則則放在最後；排在後面的規則不會因此取得覆蓋前面規則的特殊權限。

一條規則中的條件如何組合

同一條規則中的不同條件通常必須同時符合。例如同時填入 inboundTag 與 domain，表示來源入口與網域都必須符合，而不是符合其中一項即可。同一條件中的清單通常表示多個可選值，例如兩個網域擇一符合。若要表達兩組各自獨立的條件，應拆成兩條規則，避免將原本想表達的「或」誤寫成「且」。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "inboundTag": ["local-socks"],
        "domain": [
          "full:example.com",
          "domain:example.org"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "127.0.0.0/8",
          "10.0.0.0/8",
          "172.16.0.0/12",
          "192.168.0.0/16",
          "::1/128",
          "fc00::/7",
          "fe80::/10"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

這是與前述基準設定相容的路由欄位片段。第一條規則只適用於指定的 SOCKS 入站；HTTP 入站即使存取相同網域，也不會命中。第二條列出迴圈、私有及部分本機位址範圍，但並非完整的特殊用途位址資料庫。若實際設定需要更完整的位址分類，請使用經過確認的資料集，並了解其更新方式與涵蓋範圍。

網域表示式要區分比對精確度

full: 用於比對完整網域，適合指定單一主機名稱；domain: 則用於比對指定網域及其子網域。不加前綴的表示式可能會以關鍵字比對，範圍可能比預期更廣。正規表示式也會受到 JSON 跳脫規則影響，過度寬鬆的表示式會增加理解與維護難度。若能用完整網域或網域後綴表示，建議優先採用較明確的寫法。

網域規則比對的是請求攜帶或核心辨識到的目標資訊，不是網頁最後跳轉後載入的所有資源。一個頁面可能同時請求多個網域，因此首頁使用指定出口，不代表圖片、介面或影片也會走同一出口。診斷規則時，應選擇單一目標請求觀察，不要把整個網頁的綜合結果當成某條網域規則的直接證據。

解析策略會改變比對流程

AsIs 不會為了路由中的 IP 比對而主動解析網域；如果請求本身已經是 IP，仍可比對 IP 規則。IPIfNonMatch 會在網域目標未符合現有規則時嘗試解析，再進行比對。IPOnDemand 則會在路由處理需要 IP 資訊時觸發解析。這些都不是系統 DNS 開關，也不是出站的網域解析策略。

切換至會觸發解析的策略，可能改變延遲與規則命中結果。若 DNS 回傳不同地區的位址，部分 IP 分類規則可能因此選擇不同出口。反過來說，若應用程式已在核心外將網域轉成 IP，只修改核心的網域解析策略也無法還原原始網域。分析時應一併考量入站協定、嗅探與應用程式的解析方式，而不是不斷更換 DNS 位址。

以例外、分類與兜底規則組織

可先放置需要明確拒絕或指定出口的精確目標，再加入本機網路與業務分類，最後處理其餘請求。實際順序取決於使用情境，但每條規則都應能說明為何放在目前位置。若在最後加入一條涵蓋所有目標的規則，後續規則就不會生效；若不設定末尾規則，則應明確接受第一個出站作為預設出口的結果。

使用 geosite: 或 geoip: 分類時，需要有相應的資料檔與有效分類名稱。核心支援某種語法，不代表部署環境已包含所需資料。更新後若某個分類載入失敗，請先檢查資料路徑與分類標籤是否存在，不要直接刪除所有分流規則。產生的設定檔、用戶端內建規則與自訂規則也可能有不同的排序方式，請一律以執行中的設定為準。

調整規則後，透過日誌確認目標、來源與出站是否符合預期。若遇到「部分網站正常、部分無法使用」，應先比較實際命中的出口，再檢查 DNS 與連線過程。只看用戶端的總開關或節點顏色，無法確認個別請求的路由。長期維護時，為規則群組留下簡短說明，比不斷追加重複規則更容易回復與維護。

05 / DNS

dns 解析與連線路徑

排查 DNS 問題時，應先確認「由誰解析」。應用程式可以自行查詢，作業系統可以代為解析，核心也有內建解析器；遠端代理則可能在另一端解析目標網域。頂層 dns 主要設定核心內建解析器的行為，不會自動改寫裝置上所有應用程式的 DNS 設定。即使在設定中填入解析伺服器位址，也仍須確認實際請求是否經過該解析器。

區分解析位置與查詢出口

使用 SOCKS 時，應用程式可能直接將網域交給代理，也可能先在本機取得 IP 再發起連線。HTTP 代理請求通常可以帶上網域，但個別應用程式仍可能先行解析。虛擬網路接管情境也涉及 DNS 請求的攔截方式。只有先確認交給核心的是網域還是 IP，才能判斷網域路由、內建 DNS 與出站解析各自是否參與。

以下是 dns 欄位片段，示範靜態主機對應、伺服器清單與位址族選擇。範例使用可連線的公共解析位址，但實際網路可能限制其連線，也可能需要組織內部的解析服務。請依自身網路環境選擇，不要直接複製位址後就認定所有解析問題都已解決。

{
  "dns": {
    "hosts": {
      "example.com": "192.0.2.10"
    },
    "servers": [
      "1.1.1.1",
      "8.8.8.8"
    ],
    "queryStrategy": "UseIPv4"
  }
}

192.0.2.10 是文件專用的示例位址，這項對應只用來展示格式，並非可用的網站服務。使用靜態對應時應審慎評估：它會將受影響的網域固定至指定位址，可能破壞負載平衡、服務遷移與憑證對應。測試完成後請移除示例對應，再以實際需要的網域及確認無誤的位址建立正式規則。

DNS 策略不等同於路由策略

queryStrategy 控制內建 DNS 查詢或回傳位址時偏好的位址族；路由中的 domainStrategy 控制比對時是否為網域取得 IP；直連出站也可能有自己的網域解析策略。這些名稱都與解析有關，但作用位置不同。只修改頂層 DNS，不代表直連出站一定會以相同方式使用解析結果，也不代表每個遠端代理出站都會在本機解析目標。

以傳統直連出站為例，若要使用內建解析結果，可依核心支援情況設定相應策略。以下片段為直連出站加入 UseIP，表示連線至網域時先取得 IP。這不會決定路由階段的比對順序，也不會修改其他出站。可用的策略名稱及位址族細分值，仍應以目前執行核心的欄位定義為準。

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {
        "domainStrategy": "UseIP"
      }
    }
  ]
}

DNS 查詢本身也必須能夠送出

內建 DNS 發出的網路查詢需要有可用的連線路徑。不同伺服器形式，例如一般位址、加密解析位址或本機系統解析，可能採用不同的連線機制，不一定都遵循相同路由。為 DNS 請求加上標籤並單獨分流屬於進階設定，應確認目前核心的支援方式；不能假定任何 DNS 位址都會自動經過目前選取的遠端節點。

還要避免啟動依賴循環。假設遠端節點位址是網域，而解析伺服器只能透過該遠端節點存取，建立遠端連線前所需的解析可能就無法完成。加密解析服務本身若也是網域，也需要先行解析。排查時應先確保節點位址與解析服務的初始解析路徑可用，再討論所有業務網域最終應在哪裡解析。

位址族、快取與分域解析

裝置有 IPv6 位址，不代表前往目標的 IPv6 路徑正常。只查詢 IPv4 有助於縮小部分問題範圍，但不一定適合作為所有環境的長期解法。若只有某個位址族無法使用，請檢查路由、網路介面與上游連線。雙堆疊網路中的解析結果與實際連線選擇可能不同，應搭配日誌中的目標位址判斷，不能只看 DNS 回傳清單的第一項。

更換伺服器後，應用程式、系統、核心與上游都可能仍保留快取。驗證時請關閉舊連線，依用戶端提供的方式重新啟動相關元件，必要時清除系統快取，再發起新請求。既有連線繼續使用舊位址，不能證明新設定沒有儲存。也要避免同時清除快取、更換節點及修改規則，否則即使問題解決，也無法判斷真正原因。

依網域選擇解析伺服器時，規則清單、預期位址範圍與回退設定可能互相影響。只有確實需要不同的解析結果時，才增加複雜設定，並記錄每組網域的用途。尤其是內部網域，應交由能夠辨識它的內部解析服務處理。若連線已建立但網頁仍無法開啟，可參閱連線後無法上網的排查清單，繼續檢查系統代理、路由與目標服務。

06 / POLICY

policy 連線與統計策略

policy 用來設定各使用者等級的連線行為，以及部分系統層級的統計開關。它不是分流規則，不負責選擇節點，也不會因為調小逾時數值就讓連線變快。許多設定不必手動調整策略也能正常運作；只有在有明確的資源管理、連線保留或統計需求時，才值得逐項調整並觀察實際流量。

等級物件與使用者欄位如何關聯

levels 使用等級編號作為物件鍵，例如 "0"。協定使用者物件中的 level 用來選擇策略等級，但不同協定的使用者結構並不相同。有些本機入站設定也提供預設使用者等級。不能任意將 level 放在頂層，也不能依節點清單的排序推斷使用者等級。

以下策略欄位片段示範等級與系統統計設定的層級。列出的數值是教學範例，不是適用所有網路的建議參數。實際核心可能採用不同預設值或行為細節，尤其是連線重用、不同傳輸方式及協定實作，請先確認目前的支援情況。沒有明確需求時，保留預設策略通常比複製一組所謂的最佳化參數更容易維護。

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

逾時欄位處理的是哪一類問題

handshake 控制相關連線在握手階段的時間限制，不等於網頁從開啟到載入完成的總時間。若握手受到網路延遲、上游回應或協定協商影響，過短的限制會提早中止原本可能成功的連線。遇到握手逾時時，請先檢查伺服器位址、連接埠與安全參數，再判斷是否真的需要調整時間限制。

connIdle 限制閒置連線的保留時間。聊天、推播與長輪詢可能會長時間處於低流量狀態，過度縮短閒置時間會增加重新連線的次數。另一方面，長期保留大量不使用的連線也可能占用資源。評估時應觀察閒置連線中斷是否造成服務異常，而不是只因活動連線數量下降，就認定設定已獲得最佳化。

uplinkOnly 與 downlinkOnly 適用於連線一側結束後，另一側仍可繼續傳輸的階段，不是一般所說的上傳限速與下載限速。不可用它們來設定頻寬配額。某些協定或傳輸層對半關閉的處理方式不同，若發生單向傳輸中斷，應搭配協定行為與日誌排查，不宜只調高這兩個數值。

統計開關不等於完整統計系統

啟用策略中的統計欄位，只代表允許相關計數，不等於自動提供視覺化面板。完整統計通常還需要統計模組、相應的管理介面及讀取工具。使用者層級的統計也需要可識別的使用者資訊。若用戶端已經產生這些設定，建議優先確認用戶端的完整實作，不要另外新增相同連接埠的管理入口，以免發生衝突。

用戶端顯示的流量也未必等同於核心中的單一計數器。系統接管範圍、連線重試、協定額外負載與計數位置都會影響數值。比較流量前，應先說明統計所在的層級、起算時間，以及是否包含所有入口。不能將介面中的某個數字直接當成上游服務的計費依據，也不應在不了解統計範圍時就判定計數錯誤。

依實際情境驗證，而非追求通用參數

調整策略時應依據實際使用情境進行驗證。短時間的網頁請求可檢查首次連線與連續請求；長連線應用程式則要觀察閒置後是否能恢復傳輸；大型檔案傳輸則要確認單向結束與連線保留設定不會造成傳輸中斷。每次只修改一個欄位，並記錄原值、測試方式與結果，才能區分網路波動與策略本身的影響。

裝置資源不足時，也應檢查是否重複執行核心、測速工作過多或有不必要的背景請求。策略不是解決所有資源問題的總開關。若沒有證據顯示連線管理是瓶頸，先清除多餘工作與失效入口，通常比縮短所有逾時時間更直接。需要復原時，請回到用戶端的預設策略，再以相同方式重新測試，避免長期保留來源不明的參數。

07 / LOG

log 日誌與錯誤定位

日誌用來說明某次請求發生了什麼，不能只憑一條英文錯誤訊息就判定問題出在哪裡。應搭配請求時間、入站來源、目標位址、出站標籤與後續狀態一併分析。背景應用程式會持續發起連線，若同時測試多個網站，很容易將其他請求的錯誤誤認為目前操作造成。開始診斷前，先縮小流量範圍，再重現單一明確目標。

日誌層級與輸出位置

loglevel 控制錯誤日誌的詳細程度，常見層級包括 debug、info、warning、error 與 none。平時可採用較精簡的層級，排查路由與連線時再暫時提高詳細程度。詳細日誌可能包含大量內容及目標資訊，問題定位後應還原原本設定，避免長期累積不必要的資料。

{
  "log": {
    "access": "access.log",
    "error": "error.log",
    "loglevel": "info"
  }
}

以下是輸出至檔案的欄位片段。相對路徑通常是相對於程序的工作目錄，不一定是設定檔所在的目錄。圖形化用戶端也可能接管標準輸出，並顯示在執行日誌視窗中。若找不到檔案，請先確認啟動方式、工作目錄與目錄寫入權限，不要因此判定核心沒有執行。若需要固定位置，請使用本機實際存在且允許寫入的路徑。

存取日誌與錯誤日誌的用途不同。存取紀錄有助於觀察請求接收與處理路徑；錯誤紀錄則著重於異常過程，但出現存取紀錄不代表目標內容最後已完整傳輸。不同核心與日誌層級呈現的欄位也可能不同。若未看到預期的出站標籤，可暫時提高日誌詳細程度，或回到實際執行設定檢查規則，不要只憑這點猜測預設路徑。

依處理流程判讀常見錯誤

出現 connection refused 時，通常表示目標位址對應的一端明確拒絕連線。若目標是本機代理連接埠，請先確認核心是否正在監聽；若目標是遠端節點連接埠，請檢查服務是否運作，以及位址與連接埠是否正確。這不一定代表驗證失敗，因為驗證通常發生在連線建立之後；必須先辨認日誌中的位址屬於哪個層級。

i/o timeout 表示某個讀寫階段超過等待時間，但可能發生在建立連線、握手或傳輸期間。位址無法連線、沒有收到回應、路徑遺失封包或協定錯誤，都可能呈現類似狀況。請查看同一請求之前的紀錄，確認最後完成到哪個階段。單純調高所有逾時參數，通常只會延長等待時間，無法修復連線路徑。

遇到 TLS 相關錯誤時，應檢查系統時間、伺服器名稱、憑證鏈與安全設定。使用 IP 連線與以網域進行驗證可能有不同要求，傳輸層主機名稱也不等於憑證名稱。若伺服器要求特定安全協定，而用戶端設定成另一種，即使連接埠可連線，握手仍可能失敗。此時應修正欄位組合，而不是停用所有驗證選項。

分開處理啟動錯誤與執行錯誤

啟動前發生錯誤，通常與 JSON 語法、欄位型別、不支援的協定、資料檔或連接埠綁定有關。請先讓核心穩定啟動，再測試網路。執行期間發生錯誤，則應追蹤個別請求。若用戶端不斷啟動又退出，不要把反覆出現的啟動提示當成正常運作；請找出第一個致命錯誤，後續的連線失敗可能只是核心已退出所造成。

遇到找不到標籤時，先檢查規則引用與出站陣列；分類資料載入失敗時，確認資料檔與分類名稱；發生權限錯誤時，檢查輸出目錄及接管功能所需權限。不要為了消除錯誤訊息就直接刪除整個模組。每項錯誤都應對應到特定設定物件，盡可能只在該物件範圍內修正，再重新執行相同的啟動或請求測試。

保留必要資訊並隱去敏感內容

分享日誌尋求協助前，請移除身分資訊、完整訂閱網址、遠端節點憑證，以及不希望公開的存取目標。也要檢查截圖中的視窗標題、剪貼簿內容與側邊欄。為保留排查價值，可留下欄位名稱、錯誤類型、相對時間順序與匿名化標籤；不要只截取最後一行而省略重要前後文。

建議記錄測試時間、使用入口、測試目標、預期出口與實際結果，建立完整的排查紀錄。若修改規則後錯誤內容完全沒有變化，請確認執行中的設定檔確實已更新、舊程序確實停止，以及測試應用程式沒有重用舊連線。更多錯誤訊息的說明可參閱v2rayN 執行日誌判讀方法；最終仍應以目前的設定與同一次請求為準。

也要控制日誌檔案的保留範圍。長時間執行的環境應運用用戶端功能定期清理或輪替日誌，避免磁碟用量持續增加。刪除仍在寫入的檔案後，是否能立即釋放空間取決於系統行為，因此維護前最好先停止相關日誌輸出或關閉核心。保留日誌是為了重現與診斷問題，不是無限期記錄所有存取。

08 / VALIDATION

設定驗證與變更維護

設定驗證應分為文字、結構、啟動、路徑與實際使用五個層次。文字可解析不代表欄位有效，欄位有效不代表連接埠能監聽，連接埠能監聽不代表請求會命中正確出口，而連線成功也不代表所有應用程式都已納入接管。逐層檢查，才能避免在上游問題尚未解決時，不斷修改下游參數。

保留原始設定並記錄變更目的

修改前先保存一份已知可用的設定，並記錄適用的用戶端、核心與運作模式。備份應存放在受控位置，不要任意同步或公開含有身分資訊的檔案。檔名可註明用途與本機維護日期，但不要只依賴「最終版」這類含糊名稱。回復時必須知道該備份對應哪組入口、出口與規則，而不只是知道檔案曾經可以開啟。

每次變更都要寫明預期效果，例如「指定網域改走直連」或「新增測試入口」，接著設計能直接驗證效果的請求。如果目標只是修復某個網域，就不應順便更換所有 DNS 與連線策略。變更範圍愈小，測試失敗時需要檢查的差異就愈少，也更容易判斷是否應該撤銷這次修改。

第一層：檢查語法與結構

使用本機編輯器的 JSON 診斷功能檢查括號、引號、逗號與欄位型別，避免將設定上傳至不明的線上工具。接著逐一檢查頂層物件的位置：嗅探設定屬於單一入站，出站設定應放在對應出站，規則則位於 routing.rules。結構位置錯誤有時比拼字錯誤更難察覺，因為整份檔案仍可能通過一般 JSON 解析。

接著檢查所有引用：規則中的出口標籤是否存在、入站標籤是否逐字相符、分類名稱是否存在於目前的資料檔，以及日誌路徑是否可寫入。標籤不是會自動同步的變數引用，修改一端不會連帶更新另一端。建議在對照表中同時記錄顯示名稱與實際標籤，避免將用戶端介面名稱誤認為核心欄位值。

第二層：啟動與本機路徑

使用用戶端提供的設定檢查或執行資訊，確認核心能否載入設定。不同核心的命令列檢查方式可能不同，本頁不會將某一種啟動參數當成通用命令。啟動成功後，檢查本機監聽是否正常，再讓支援代理的測試應用程式明確使用該入口。若沒有接收紀錄，請重新檢查代理位址、連接埠、應用程式設定與系統授權。

可以先回復第一章的完整直連基準設定，確認本機請求能否被接收並送出。若基準設定也失敗，就不必急著研究遠端節點的安全參數。若基準設定成功、自訂設定失敗，則依序檢查入站、出站、路由、DNS 與策略。每恢復一個部分就重新啟動並測試，找出第一次出現差異的位置。

第三層：複核路由與實際使用情境

選擇一個預期會走指定出口的目標，再選擇一個不應受該規則影響的目標作為對照。記錄兩者實際使用的出站，確認規則沒有擴大適用範圍。網域規則還要考慮子網域、頁面資源與重新導向；連接埠規則則須區分目標連接埠與本機監聽連接埠。對照測試比單次確認網頁能開啟，更能證明規則含義與實際行為一致。

相同的核心設定在不同系統上，檔案路徑、監聽權限與網路接管入口可能不同。應用程式本身的網路設定也不一定會跟隨桌面環境。不能只更換節點，就認定另一台裝置也具備完全相同的連線路徑。首次移轉時應重新驗證入口與授權，再沿用協定與路由邏輯。

更新、回復與日常查閱

更新用戶端或切換核心後，先保留舊設定與變更紀錄，再確認產生的設定是否仍包含原有規則。更新訂閱主要影響節點資料，通常不等於完整執行設定的版本管理。若自訂欄位遭到覆蓋，應改用用戶端支援的持久設定入口，不要將反覆修改暫存檔當成固定維護流程。

發生問題時，優先撤銷最近一次相關變更，再重複相同測試。恢復正常後比較前後差異，找出具體欄位，而不是永久換回整份舊檔卻不再分析。若涉及核心差異，可先保留原有協定與傳輸組合，避免在同一次回復中更換用戶端、核心、節點與規則，導致測試條件全部改變。

日常連線操作請依照入門教學的主要流程；需要更換平台或選擇用戶端時，請參閱三款用戶端比較，安裝套件請至下載頁。本頁則依欄位提供查閱方向：接收問題看入站，出口問題看出站，規則命中異常看路由，網域問題看 DNS，連線保留問題看策略，最後透過日誌與對照測試驗證判斷。