V2Ray 設定檔完整參考

01 / ROOT OBJECT

JSON 結構總覽與資料流邊界

頂層物件不是執行步驟清單

V2Ray 設定檔的根節點是一個 JSON 物件。常見的頂層欄位包括 log、dns、inbounds、outbounds、routing、policy 與 stats。這些欄位在檔案中的書寫順序通常不會決定執行順序：將 routing 寫在 inbounds 前面，不代表路由會先於入站啟動。實際的執行關係由模組職責與標籤引用構成，因此整理設定時可以依閱讀習慣排序，但不要把視覺順序當成控制流程。

inbounds 與 outbounds 都是陣列，因為單一核心執行個體可以同時監聽多個入口，也能準備多個出口。陣列中的每個物件通常透過 tag 取得固定名稱。路由規則使用 inboundTag 限定來源，再透過 outboundTag 指向目標出口。標籤是設定內部的參照鍵，不是協定名稱；將出口標籤命名為 proxy、direct 或更具體的角色名稱都可以，前提是引用完全一致且便於維護。

JSON 語法與用戶端產生的設定

標準 JSON 要求屬性名稱與字串使用雙引號，不允許尾隨逗號，也不支援原生註解。布林值必須寫成 true 或 false，連接埠等數字不應寫成帶引號的字串。中文、路徑與網域可以直接放入 UTF-8 檔案，但 Windows 路徑中的反斜線需要跳脫。手動編輯後若出現「無法解析設定」之類的錯誤，應先檢查語法，再檢查協定欄位；語法解析失敗時，核心尚未進入網路連線階段。

v2rayN、v2rayNG 與 v2flyNG 會依照介面設定產生或組合核心設定。桌面端首選 v2rayN，適合檢視路由、系統代理與核心日誌；Android 上的 v2rayNG 使用 Xray 核心，v2flyNG 使用 V2Fly 核心。用戶端產生的暫存設定可能在重新啟動、切換節點或更新訂閱後被覆寫，因此長期規則應透過用戶端提供的自訂設定、路由設定或支援的範本入口維護，不宜直接修改執行目錄中的暫存檔案。

{
  "log": {
    "loglevel": "warning"
  },
  "dns": {
    "servers": [
      "1.1.1.1",
      "8.8.8.8"
    ]
  },
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": []
  }
}

最小設定只需要一個可接收流量的入站與一個可建立連線的出站，但實際用戶端還會加入本機 API、統計、DNS 或多組路由。閱讀大型設定時，可以先隱藏與目標問題無關的模組：連線完全無法啟動先看 JSON、入站與出站；只有部分網域走錯出口再看路由；網域失敗而 IP 可用則優先檢查 DNS。依故障邊界縮小範圍，比逐行盲目修改更可靠。

02 / INBOUND

inbounds 入站監聽、協定與流量識別

listen、port、protocol 與 tag

入站決定哪些本機或網路連線可以進入核心。常見的本機入口是 SOCKS 與 HTTP 代理：瀏覽器、終端機或系統代理將請求送到該監聽位址，核心再處理後續路由。listen 設為 127.0.0.1 時只接受本機連線，適合單機用戶端；設定為監聽所有介面會擴大可存取範圍，除非明確需要區域網路裝置接入，否則不應任意開放。port 必須未被其他程式占用，同一位址與連接埠組合不能由兩個入站重複繫結。

protocol 指定入口協定，settings 的結構會隨協定變化。SOCKS 入站常用 udp 控制 UDP 轉發，HTTP 入站則接收一般 HTTP 代理與 CONNECT 請求。tag 用於讓路由識別來源，例如將瀏覽器專用入口標記為 browser-in，就能讓該入口使用獨立規則。標籤不能取代連接埠：應用程式仍需連線到正確的監聽連接埠，路由模組才有機會讀取標籤。

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

sniffing 的用途與邊界

當應用程式只將目標 IP 交給代理，而路由規則需要依網域判斷時，sniffing 可以從 HTTP 請求或 TLS 交握中識別目標網域。destOverride 表示允許識別哪些流量類型。啟用後，路由模組可取得更完整的網域資訊，依網域分流的命中率通常更穩定；但嗅探不是 DNS 的替代方案，也無法從所有加密流量中還原任意內容。它只利用建立連線階段可見的目標資訊。

排查嗅探相關問題時，應分別觀察「應用程式提交的原始目標」與「路由實際使用的目標」。如果關閉嗅探後規則恢復正常，可能是識別出的網域觸發了另一條更前面的規則；如果開啟後網域規則仍未命中，應確認流量確實經過該入站，而不是由系統中的另一個代理連接埠接收。透明代理、虛擬網卡與一般 SOCKS 入口的流量來源不同，用戶端介面啟用某種模式後，實際產生的入站也會改變。

入站故障通常表現為應用程式無法連線到本機代理、連接埠繫結失敗或 UDP 請求單獨失效。應先用用戶端日誌確認監聽是否成功，再檢查系統代理位址與連接埠。若瀏覽器可用而某個應用程式不可用，重點檢查該應用程式是否支援所選代理類型、是否繞過系統代理，以及是否需要 UDP。在尚未確認本機入口可達前，不要反覆更換遠端節點，因為流量可能根本沒有進入核心。

03 / OUTBOUND

outbounds 出站協定物件與出口選擇

遠端出口、直連出口與阻斷出口

出站負責將路由選中的連線送往最終目標或遠端服務。完整設定通常至少包含遠端代理出口與直連出口，並可依需求加入阻斷出口。遠端出口的 protocol 可以是 VMess、VLESS、Trojan 等用戶端與伺服器共同支援的協定；settings 儲存伺服器位址、連接埠與驗證資訊；streamSettings 描述底層傳輸、安全層及相關參數。欄位必須與伺服器設定成對，協定名稱正確並不代表傳輸參數可以互換。

freedom 表示由目前裝置直接存取目標，通常將標籤設為 direct。blackhole 用於主動終止規則選中的連線，通常將標籤設為 block。它們仍是標準出站，因此路由規則只需更換 outboundTag，不必使用特殊動作語法。若規則引用不存在的標籤，設定可能載入失敗，或在執行階段找不到目標出口；修改標籤後必須同步搜尋所有引用。

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "server.example.com",
            "port": 443,
            "users": [
              {
                "id": "11111111-2222-3333-4444-555555555555",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "serverName": "server.example.com"
        }
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {
        "response": {
          "type": "none"
        }
      }
    }
  ]
}

streamSettings 需要整體核對

streamSettings.network 描述底層傳輸，例如 TCP、WebSocket 或 gRPC；security 描述 TLS、REALITY 等安全層選擇。與特定傳輸相關的設定位於對應子物件中，例如 WebSocket 使用路徑與請求標頭，TLS 使用服務名稱等參數。排錯時應將遠端出站拆成三層：先確認伺服器位址與連接埠可達，再確認使用者驗證資訊與協定一致，最後確認傳輸與安全層細節一致。只看到「連線已關閉」無法直接判斷是哪一層出錯。

如果伺服器位址使用網域，核心必須先完成解析，因此出站失敗也可能由 DNS 引起。若日誌顯示已解析出位址但交握失敗，應轉向檢查協定、時間、服務名稱與傳輸參數；若連解析結果都沒有，則先檢查 dns 設定與系統網路。使用 IP 直接測試有助於區分解析與連線問題，但 TLS 情境通常仍需要正確的服務名稱，不能把 IP 測試結果直接當成最終設定。

mux 等連線多工設定，應在確認基本連線穩定後再調整。多工並非在所有網路與協定下都一定更快，過早加入最佳化參數反而會增加變數。建立設定時可先保留一個遠端出口、一個直連出口與最少的傳輸欄位，成功後再逐步加入路由、多工或其他出口。每增加一層都記錄變更，發生問題時就能快速定位。

用戶端匯入訂閱後會自動產生遠端出站，手動覆寫前應先了解更新機制。訂閱更新可能替換節點參數，但本地路由通常由用戶端獨立管理。需要重新取得用戶端時可前往取得用戶端，想了解分享連結與訂閱網址的差異，可閱讀分享連結與訂閱匯入說明。

04 / ROUTING

routing 路由比對順序與分流規則

規則依順序命中，不會自動合併

路由模組讀取連線屬性並選擇出站。rules 是有順序的陣列，通常由上到下檢查，連線命中一條可執行規則後，就會使用該規則指定的出口。因此越具體、越需要優先處理的規則應放在前面，範圍寬泛的兜底規則則放在後面。即使兩條規則的條件部分重疊，也不會自動計算「越具體者優先」；實際優先順序取決於陣列位置。

常用條件包括 domain、ip、port、network、inboundTag 與 protocol。同一規則中放入多個不同類別的條件時，連線通常需要同時符合這些類別；同一類別陣列中的多個值則表示符合其中之一。例如一條規則同時寫入網域與連接埠，就只會處理同時符合網域條件且位於該連接埠範圍內的連線。將彼此無關的條件塞進同一條規則，常會造成規則看似完整卻始終無法命中。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "domain:example.cn",
          "full:intranet.example"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "geosite:category-ads-all"
        ],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

網域、IP 與 domainStrategy

網域條件可以使用不同的比對形式。full: 表示完整網域比對，適合固定主機名稱；domain: 可涵蓋指定網域及其子網域；regexp: 提供正規表示式比對，但複雜表達式會降低可讀性，應只在一般比對無法表達時使用。geosite: 引用核心資料檔中的網域集合，集合是否可用取決於用戶端是否附帶對應資料資源。寫入名稱不代表目前環境一定存在相應集合，載入錯誤或規則無效時應查看日誌。

IP 條件支援單一位址、CIDR 網段與 geoip: 集合。私有位址通常應優先直連，避免將區域網路服務送往遠端出口。網域條件是否需要先解析為 IP，取決於 domainStrategy。AsIs 主要依原始網域比對；IPIfNonMatch 在網域規則未命中時嘗試解析，並繼續檢查 IP 規則；IPOnDemand 則會更積極地為 IP 規則觸發解析。更積極的解析策略可能增加 DNS 查詢，也可能改變分流結果，不能只看名稱就判斷哪個「更進階」。

驗證路由時不要只看網站是否開啟，因為多個出口都可能成功。應暫時將目標網域放入一條位置靠前、標籤明確的規則，再從日誌確認它選用了哪個出口。若規則未命中，依序檢查流量是否經過預期入站、嗅探是否提供網域、比對前綴是否正確、規則位置是否被前項攔截，以及出口標籤是否存在。關於 DNS 分流與避免污染的完整做法，可繼續閱讀V2Ray DNS 分流解析指南。

05 / DNS

DNS 設定伺服器選擇、hosts 與解析路徑

內建 DNS 只處理進入其路徑的查詢

dns 模組定義核心如何解析網域，但設定 DNS 伺服器不代表系統中所有查詢都會自動改走核心。應用程式可能自行解析，也可能由作業系統先解析後，只將 IP 交給代理。是否進入內建 DNS，取決於用戶端模式、入站類型、路由策略與應用程式行為。因此遇到 DNS 問題時，第一步不是不斷更換伺服器位址，而是先確認查詢發生在哪一層。

servers 可以放入簡單位址，也可以放入帶有網域比對條件的伺服器物件。簡單寫法依清單提供通用解析來源；物件寫法可用 domains 指定某類網域優先交給特定伺服器，並透過 expectIPs 限定預期的位址範圍。hosts 用於靜態對映或別名，在已知固定結果、內部服務對映與測試規則時很有用，但不適合維護大量頻繁變動的公共網域。

{
  "dns": {
    "hosts": {
      "domain:internal.example": "192.168.10.20",
      "dns-alias.example": "target.example"
    },
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": [
          "geosite:cn"
        ],
        "expectIPs": [
          "geoip:cn"
        ]
      },
      {
        "address": "1.1.1.1",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      "localhost"
    ],
    "queryStrategy": "UseIP"
  }
}

查詢策略與 DNS 出站

queryStrategy 控制查詢位址族群的偏好，例如同時允許 IPv4 與 IPv6，或只請求其中一種。選擇前應確認目前網路、遠端出口與目標服務是否確實具備對應位址族群的連通性。若網路沒有穩定的 IPv6 路徑，卻優先取得 IPv6 結果，可能會出現解析成功但連線逾時；這不是 DNS 伺服器失效，而是解析結果與實際出口能力不一致。

進階設定可以加入 dns 協定出站，並透過路由讓核心發起的 DNS 流量經由指定出口。此時需要同時檢查三個物件：dns.servers 決定向誰查詢，DNS 出站決定如何傳送查詢，routing.rules 決定這類流量選擇哪個出口。只修改其中一個物件，可能產生查詢迴圈或與預期相反的路徑。尤其不要讓用於解析遠端伺服器網域的 DNS 請求，依賴尚未建立的同一個遠端連線。

{
  "outbounds": [
    {
      "tag": "dns-out",
      "protocol": "dns"
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "protocol": [
          "dns"
        ],
        "outboundTag": "dns-out"
      }
    ]
  }
}

DNS 排錯可以採用固定順序：先用系統工具確認裝置本身已連上網路，再從核心日誌確認是否發起查詢、查詢交給哪個伺服器，以及返回哪類位址，最後確認該位址能否經由選定出口連線。如果網域存取失敗而直接存取測試 IP 能建立 TCP 連線，應繼續檢查網域解析與 TLS 服務名稱；如果解析有結果但所有位址都逾時，應檢查路由與出口。清除快取只能移除舊結果，無法修正錯誤的規則鏈。

分流設定應保持可解釋性。將本地域名、本地位址與明確的內部服務交給本地解析，其餘請求再依需求選擇遠端解析，是比堆疊大量例外更穩定的起點。每次修改只變更一個變數，並記錄修改前後的查詢日誌。詳細欄位拆解與避免解析洩漏的實作方式，可結合前述DNS 設定詳解繼續核對。

06 / POLICY

policy 策略連線時限、統計與資源限制

level 與策略物件的對應關係

policy 用於設定使用者層級與系統層級的執行策略。使用者層級策略位於 levels，鍵名是等級數字的字串；協定使用者物件中的 level 決定使用哪一組策略。它不是網路品質評分，也不代表權限高低，而是將一組連線參數對應給指定使用者。多數單一使用者用戶端使用等級 0 即可，只有確實需要區分多組連線行為時才增加等級。

常見的使用者層級欄位包括交握逾時、連線閒置時間、僅上行或僅下行時的保留時間，以及是否啟用使用者上行與下行統計。時間欄位的具體單位與生效邊界，應配合核心文件與日誌確認，不能把所有數值都視為毫秒。數值設得過短會讓長連線、背景同步或低頻請求提早中斷；設得過長則可能讓失去活動的連線占用資源。最佳化前應先觀察實際故障，不要把策略物件當成通用加速開關。

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

policy、stats 與 API 的關係

開啟策略中的統計開關，只代表允許收集相應維度的資料；頂層通常還需要存在 stats 物件。若用戶端介面需要讀取統計資訊，也可能產生本機 API 入站與相關路由。三者職責不同：policy 決定啟用哪些維度，stats 啟動統計模組，API 則提供讀取入口。只複製其中一段，介面可能仍然看不到資料。

統計會增加一定的執行負擔，實際是否需要取決於用戶端功能。只為確認連通性時，日誌往往比累計統計更直接；需要長期觀察入站與出站流量時，再啟用對應維度。不要為了「設定完整」而開啟所有開關，也不要根據短時間統計值判斷協定優劣。應用程式快取、並行連線、系統更新與背景工作都會影響觀察結果。

策略排錯應從預設值開始。若某類連線在固定閒置時間後中斷，可以對照 connIdle；若遠端網路偶爾變慢時才失敗，可以檢查交握時間是否設得過低；若只有統計缺失但連線正常，則檢查統計開關、頂層模組與用戶端 API，而不是修改出站協定。將連線行為與觀測行為分開，能避免為修復介面顯示問題而破壞正常鏈路。

用戶端可能依圖形介面自動管理策略與統計項目。手動設定與用戶端設定並存時，應先確認最終產生的檔案，而不是只查看自訂片段。v2rayN 更適合在桌面環境檢查產生結果與日誌；v2rayNG、v2flyNG 的行動端設定通常由應用程式管理，手動欄位應透過其支援的入口匯入。不同核心對擴充欄位的接受範圍可能不同，遷移設定時應從核心欄位開始逐段加入。

07 / LOGGING

日誌與觀測：從錯誤階段定位模組

loglevel 決定資訊密度

log 是設定排錯的第一個入口。常用 loglevel 由詳細到精簡可包含 debug、info、warning、error 與 none 等等級。日常執行可保留 warning；重現複雜路由或 DNS 問題時，暫時提高至 info 或 debug，記錄完成後再恢復。詳細日誌可能包含目標網域、位址、標籤與連線過程，不應直接公開未整理的完整檔案。

access 與 error 可以指定存取日誌與錯誤日誌的輸出位置。省略檔案路徑時，用戶端通常會從標準輸出或自身日誌視窗收集內容。相對路徑以程序工作目錄為基準，不一定是設定檔所在目錄；在受限目錄下也可能因寫入權限不足而失敗。圖形用戶端已提供日誌面板時，優先使用用戶端管理的輸出方式，避免自訂路徑與更新、權限或可攜式目錄發生衝突。

{
  "log": {
    "access": "",
    "error": "",
    "loglevel": "warning",
    "dnsLog": false
  }
}

依階段閱讀日誌，不要只搜尋 error

一條連線大致會經歷設定載入、入站接收、目標識別、DNS 解析、路由選擇、出站撥號、協定與安全層交握、資料傳輸等階段。日誌中的最後一行只是表面結果，真正原因常出現在前幾行。例如「連線關閉」可能由遠端主動中斷、交握參數不一致或上游逾時引起；「找不到出口」則更接近標籤引用問題；「位址已在使用中」發生於入站監聽階段，與節點參數無關。

排錯時先記錄重現時間與目標，然後清除舊日誌，或從該時間點附近開始閱讀。多次嘗試會產生交錯紀錄，若同時開啟多個應用程式，很難判斷哪條連線對應測試目標。可以先關閉無關程式，只保留一個瀏覽器請求，再觀察從入站到出站的完整鏈路。路由問題重點檢查入站標籤、網域或 IP 條件與最終出站標籤；DNS 問題重點檢查查詢伺服器、返回位址與後續連線；交握問題重點檢查服務名稱、傳輸、安全層與系統時間。

如果用戶端啟動後立即退出，應先確認執行環境、目錄權限、核心檔案與連接埠占用情況。Windows 桌面端也可能受到執行階段函式庫與受保護目錄寫入限制影響；Android 用戶端則需要檢查系統是否限制背景執行。相關處理步驟可查閱v2rayN 啟動崩潰與 v2rayNG 閃退排查。這類問題發生在設定鏈路之外或載入早期，不應直接歸因於遠端協定。

日誌比對比單次截圖更有價值。保留一份可用設定的啟動與連線紀錄，再與修改後的紀錄比較：是否少了某個監聽、DNS 返回是否改變、同一網域選出的出站是否不同、交握失敗發生在解析前還是解析後。比較各階段差異可以快速縮小範圍。完成診斷後，應移除臨時 debug 設定與測試規則，避免長期累積大量日誌，或讓高優先級測試規則持續影響日常分流。

08 / VALIDATION

設定驗證與排錯的固定執行順序

先語法，再引用，最後檢查網路

穩定的驗證流程應分層執行。第一層檢查 JSON 語法：括號是否配對、逗號是否正確、字串是否閉合、數字與布林值類型是否正確。第二層檢查內部引用：所有 outboundTag、inboundTag 與策略等級是否有對應物件，標籤大小寫是否一致。第三層才檢查網路：監聽連接埠、DNS、伺服器位址、協定驗證、傳輸與安全層。跳過前兩層直接更換節點，會讓簡單錯誤被網路現象掩蓋。

核心通常提供設定測試或以指定設定啟動的功能，但不同用戶端的封裝方式與核心命令參數可能不同。圖形用戶端使用者應優先查看用戶端的設定檢查與日誌入口，避免在不了解執行目錄時直接執行命令。若使用獨立核心環境，可先查看目前可執行檔的說明資訊，再依其支援的參數載入設定。驗證成功只代表結構與欄位被接受，不代表遠端服務一定可達。

{
  "log": {
    "loglevel": "info"
  },
  "inbounds": [
    {
      "tag": "test-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "inboundTag": [
          "test-in"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

用最小設定切分故障範圍

上方的最小設定只驗證本機 SOCKS 入站、路由標籤與直連出站。若它無法啟動，問題集中在語法、連接埠與本機執行環境；若它能啟動並存取目標，再替換為實際遠端出站，就能判斷故障是否進入遠端協定層。接著依序恢復 DNS、網域規則、IP 規則、阻斷規則、統計與策略。每次只恢復一組欄位，發現故障後即可將範圍鎖定在剛加入的模組。

常見錯誤可以依現象分類。啟動即失敗，多半是 JSON、未知欄位、標籤引用、連接埠衝突或檔案權限問題；本機代理無法連線，多半是監聽位址、連接埠與應用程式代理類型不一致；所有網域都失敗但部分 IP 可達，多半是 DNS 路徑問題；只有特定網域走錯出口，多半是規則順序、嗅探或比對前綴問題；連線建立後很快中斷，則需要檢查策略時限、遠端交握與網路穩定性。分類不是最終結論，但能決定先閱讀哪一段日誌。

用戶端環境還要考慮設定覆寫。v2rayN 切換節點、更新訂閱或變更路由模式後，可能重新產生執行設定；v2rayNG 與 v2flyNG 也會依應用程式設定建立核心參數。手動修改暫存檔案後短暫有效、重新啟動後失效，通常不是核心忽略設定，而是檔案被用戶端重新產生。應將長期設定放在用戶端支援的自訂路由、範本或匯入入口。

最終驗收不應只看單一網頁能否開啟。至少驗證本機位址直連、一般網域解析、預期代理網域、UDP 需求、用戶端重新啟動，以及更新訂閱後的行為，並從日誌確認出口標籤符合設計。若剛開始使用用戶端，先依使用文件完成基礎鏈路，再回到本頁加入規則；若需要重新選擇安裝套件，前往取得用戶端，依 Windows、macOS、Android 或 Linux 平台下載。複雜設定的可靠性來自清楚的邊界、逐段驗證與可回復的紀錄，而不是欄位數量。