---
title: "3x-ui 面板入站与客户端配置详解"
source: https://www.iowill.com/blog/2026/10/3x-ui-inbound-protocol-configuration/
date: 2026-10-18
updated: 2026-10-18
tags: [3x-ui, REALITY, Shadowsocks, TLS, VLESS, Xray]
categories: [系统与运维]
---

# 3x-ui 面板入站与客户端配置详解

打开 3x-ui 的“添加入站”，最容易卡住的往往不是协议名称，而是后面的字段：监听 IP 填什么，SNI 是自己的域名还是别人的网站，公钥给哪一端，WebSocket 的路径又和面板路径有什么关系。

配置一条能使用的入站，需要把四件事对应起来：服务端监听、用户认证、传输与安全、客户端参数。配置步骤按 3x-ui 面板的填写顺序组织，覆盖各类入站的导入和验证方式。

首次配置时，先根据域名与证书条件选一种方案，读完共用字段后完成对应章节；已有节点时，可以直接查阅该协议，再按文末的四项检查复测。不同章节是独立示例，无需把所有入站一起创建。

尚未安装面板时，先看[3x-ui 安装与首次连接](https://www.iowill.com/blog/2026/10/3x-ui-installation-first-connection/)。如果已有配置但一直无法使用，可以结合[面板正常但节点不可用的排查方法](https://www.iowill.com/blog/2026/10/3x-ui-panel-works-node-unusable/)检查日志和网络路径。

## 适用版本与连接方式

本文以 3x-ui `v3.10.2` 的入站编辑器为版本基线，Linux 命令沿用 Debian 12、systemd 和官方脚本安装方式，命令块使用 Bash 语法。面板、服务端 Xray、客户端 App 和客户端内置核心，分别记录实际版本；其他版本缺少某个选项时，不要直接把最新字段粘入旧配置。[3x-ui 协议与入站说明](https://github.com/MHSanaei/3x-ui/blob/v3.10.2/docs/content/docs/en/config/inbounds.mdx)

普通代理示例先采用“客户端直连节点”，不经过 Nginx 或 CDN：

```text
浏览器或应用 → 客户端本地代理 → 服务器节点端口 → 代理服务 → 目标网站
```

本文使用的公网地址 `203.0.113.10` 是文档保留地址，不能实际连接；`node.example.com`、证书路径和端口也都是示例，必须替换。`127.0.0.1` 表示执行命令的当前机器；隧道示例中的 `172.20.0.x` 是内网示意地址，使用前检查是否与现有网络重叠。代码中的中文密钥说明必须替换成自己生成的值。

为了让不同配置可以分别验证，示例使用不同端口：

| 组合或用途 | 示例端口 | 外层网络 |
| --- | --- | --- |
| VLESS + TCP + REALITY + XTLS-Vision | 24443 | TCP |
| VLESS + XHTTP + TLS | 24444 | TCP |
| VLESS + XHTTP + REALITY | 24465 | TCP |
| VLESS + WebSocket + TLS | 24457 | TCP |
| VLESS + gRPC + TLS | 24458 | TCP |
| VLESS + HTTPUpgrade + TLS | 24459 | TCP |
| VMess + WebSocket + TLS | 24445 | TCP |
| VLESS 本机练习 | 24460 | 仅回环 TCP，经 SSH 转发访问 |
| VMess + TCP | 24461 | TCP |
| Trojan + TCP + TLS | 24446 | TCP |
| Shadowsocks 传统 AEAD | 24447 | TCP；启用原生 UDP 时也开放 UDP |
| Shadowsocks 2022 | 24462 | TCP；启用原生 UDP 时也开放 UDP |
| VLESS + TCP + TLS + XTLS-Vision | 24463 | TCP |
| VMess + mKCP | 24464 | UDP |
| Hysteria2 | 24448 | UDP |
| TUIC v5 | 24449 | UDP |
| WireGuard | 24450 | UDP |
| AmneziaWG | 24451 | UDP |
| HTTP 本机代理 | 24452 | 仅回环 TCP |
| Mixed 本机代理 | 24453 | 仅回环 TCP；本例不启用 UDP |
| Tunnel 本机转发 | 24454 | 仅回环 TCP |
| MTProto | 24455 | TCP |
| MASQUE | 24456 | 按 ALPN 使用 TCP、UDP 或两者 |
| TUN 本机接管 | 无远程节点端口 | 本机虚拟网卡 |
| XDRIVE 传输 | 不按普通节点端口访问 | 存储 API 或实际共享目录 |

端口不必都是 443。多个独立 TCP 监听器不能直接占用同一个监听地址和端口；TCP 与 UDP 则分别检查。只有实际创建了哪一个入站，才为它设置相应的网络规则。

### 开启 SSL/TLS 后可以使用哪些端口

TLS 本身不限定只能使用 443 或 8443。443 是 HTTPS 的默认端口，其他可用端口也可以运行 TLS 服务；能否连接取决于实际监听、客户端和网络规则。日常说的“开启 SSL”，通常指启用 TLS。

需要区分四种端口用途：

| 使用方式 | 客户端或验证入口 | 服务端需要对应什么 |
| --- | --- | --- |
| 直连，域名仅作 DNS 解析 | 实际节点端口，如 `24444` | 节点在该端口启用 TLS，两端端口一致，证书、SNI 和网络规则正确 |
| Cloudflare 普通橙云 HTTPS 代理 | `443`、`2053`、`2083`、`2087`、`2096`、`8443` | 使用其支持的协议与传输，并核对回源设置；不能直接沿用 `24444` |
| Nginx 等反代，以 WS 为例 | 公网 `443` | Nginx 终止 TLS，再转到本机 `127.0.0.1:24457` 的明文 WS；后端安全层按此拓扑设为 none |
| Let’s Encrypt 申请与续期 | HTTP-01 用 `80`，TLS-ALPN-01 用 `443`，DNS-01 查 TXT | 验证域名控制权；证书签发后的节点监听端口可以不同 |

`80` 通常承载明文 HTTP，不在 Cloudflare 的 HTTPS 代理端口列表内。端口符合列表也不代表任意 TCP/UDP 协议都能穿过橙云；还要核对传输和服务支持。[Cloudflare 代理端口说明](https://developers.cloudflare.com/fundamentals/reference/network-ports/)

证书验证端口与节点服务端口是两个设置。申请和续期都要满足相应验证条件，不要因为节点改到其他端口就忽略续期入口。[证书验证方式](https://letsencrypt.org/docs/challenge-types/)

如果只给 3x-ui 管理面板启用 HTTPS，各入站仍按自己的端口、证书和传输设置工作。

### 本文覆盖哪些入站

“全部入站”以这个版本后端允许新建的协议为边界。WS、gRPC、XHTTP、TLS 和 REALITY 是组合中的传输或安全设置，后面另列填写步骤。

| 面板协议值 | 本文对应的配置 | 客户端从哪里拿配置 |
| --- | --- | --- |
| `vless` | TCP/REALITY、TCP/TLS、WS/TLS、gRPC/TLS、HTTPUpgrade/TLS、XHTTP，以及本机练习 | 对应用户的分享链接、二维码或 JSON 订阅 |
| `vmess` | TCP、WS/TLS；另示范 mKCP 传输 | 对应用户的 VMess 配置 |
| `trojan` | TCP/TLS | 对应用户的 Trojan 配置 |
| `shadowsocks` | 传统 AEAD、SS2022 | 对应用户的 SS 配置 |
| `hysteria` | Hysteria2 | `hysteria2://` 或兼容配置 |
| `tuic` | TUIC v5 | 分享链接或支持的 YAML 配置 |
| `wireguard` | 服务器密钥、子网和独立客户端 | 当前客户端的隧道配置 |
| `amneziawg` | 独立子网、混淆参数和客户端 | 当前客户端的 AmneziaWG 配置 |
| `http` | 带账号的回环 HTTP 代理 | 手填代理地址、用户名、密码 |
| `mixed` | 同端口 HTTP/SOCKS 代理 | 手填代理类型、地址和凭据 |
| `tunnel` | 固定目标端口转发 | 应用连接转发入口，无普通节点链接 |
| `mtproto` | Telegram 专用代理 | Telegram 代理链接 |
| `masque` | CONNECT-IP 隧道 | 支持该实现的 JSON 订阅 |
| `tun` | 本机虚拟网卡与系统路由接管 | 配置运行面板的主机，无远程节点链接 |

上表覆盖本版协议枚举与后端校验中的 14 类入站。`tun` 是运行核心的主机本地入口，`tunnel` 是端口转发，不能因名称接近而互换。[面板协议枚举](https://github.com/MHSanaei/3x-ui/blob/v3.10.2/frontend/src/schemas/primitives/protocol.ts)、[入站数据模型与校验](https://github.com/MHSanaei/3x-ui/blob/v3.10.2/internal/database/model/model.go)

## 根据域名与证书条件选择方案

有没有自己的域名，会影响证书准备和接入方式，但不能只按“买没买域名”判断协议能不能用。REALITY 的基础方案不要求你为入站申请普通 TLS 证书；Shadowsocks 使用自身的协议加密。常规 TLS 方案则要让客户端能够验证服务端证书。

| 当前条件 | 可以从哪里开始 | 配置前要确认 |
| --- | --- | --- |
| 没有自己的域名，也没有准备节点证书 | VLESS/TCP/REALITY，或客户端支持的 Shadowsocks | REALITY 的目标、SNI 和密钥；SS 的方法与凭据 |
| 已有自己的域名和有效节点证书 | VLESS/WS/TLS、VLESS/XHTTP/TLS、VMess/WS/TLS、Trojan/TLS | 解析、证书链、SNI 和实际节点端口 |
| 已准备证书，并确认 UDP 可达 | Hysteria2、TUIC | 对应客户端支持、UDP 监听和规则 |
| 想拆开验证协议和外层传输 | 后面的 VLESS 本机练习或 VMess/TCP 对照 | 保持示例的监听与信任边界 |
| 需要系统级隧道或专用转发 | 后文的 WireGuard 等扩展章节 | 对应客户端、路由和目标用途 |

这里把“已有域名的常规证书方案”作为 TLS 示例，不代表协议在技术上只允许域名证书。使用覆盖 IP 的证书或自行建立信任时，需要另外安排证书验证；勾选“跳过验证”不能代替这一步。

## 区分协议、传输与安全层

![VLESS 等代理入站的协议、传输与安全层对应关系](https://img.iowill.com/file/系统与运维/3x-ui面板入站与客户端配置详解/body1.png)

普通代理组合分开核对认证、传输和安全层；WireGuard、TUN 等使用专用表单。

“VLESS”“WebSocket”“REALITY”处在不同位置：

| 层次 | 负责什么 | 常见选项 |
| --- | --- | --- |
| 入站协议 | 用户怎样认证、代理请求怎样表达 | VLESS、VMess、Trojan、Shadowsocks |
| 传输方式 | 客户端与服务端怎样承载数据 | TCP/RAW、WebSocket、gRPC、XHTTP |
| 传输安全 | 外层连接使用哪种安全机制 | TLS、REALITY、none |

例如，VLESS 可以采用 TCP 与 REALITY，也可以采用 XHTTP 与 TLS。选择 VLESS 后，并不是所有传输、安全模式和 Flow 都能任意组合。Hysteria2、WireGuard 等协议还有自己的约束，不能套用普通 VLESS 表单的全部字段。[Xray 传输配置](https://xtls.github.io/config/transport.html)

下面的 VLESS 基础方案不启用额外的 VLESS Encryption。新版本提供的 VLESS Encryption 与外层 TLS、REALITY 不是同一个开关；要启用它，应另外生成对应参数并确认两端实现兼容，不能只把一个 `none` 改成算法名称。

## 入站与客户端的共用字段

### 先创建入站，再关联客户端

本文参考的面板把入站与客户端分开管理。进入“入站列表 → 添加”，先完成入站本身的设置并保存，再到“客户端”新建用户、选择关联入站；已有用户也可从入站的操作菜单关联进来。旧版可能直接在入站编辑框里添加用户，应按实际界面完成同一组配置。

一次配置的操作顺序为：

1.  **基础**：填备注、协议、监听地址、端口与分享地址；单机示例部署在本面板，不选择远程节点。
2.  **协议**：填该协议独有的设置，例如 VLESS 解密、SS2022 服务器密钥、WireGuard 子网或 HTTP 账号。
3.  **传输**：选择 RAW、WS、gRPC、XHTTP 等，填写路径或对应参数。没有传输选择器的协议，按其专用表单配置。
4.  **安全**：按方案选择 none、TLS 或 REALITY，填写证书或密钥。TUIC 的证书在自己的协议设置中，不照搬这个页签的位置。
5.  保存入站，确认没有服务配置错误，再创建客户端。在“关联入站”中只选这次的测试入站，并在凭据设置中填写 UUID、密码、Auth 或密钥。
6.  保存客户端，从该用户对应的入站获取配置。导入后对照本节参数，完成监听、握手和真实请求验证。

VMess、Trojan 等协议没有额外入站协议字段时，相关页签可能不显示。HTTP/Mixed 的账号直接配置在入站中；Tunnel 没有这类用户认证。后面各节的“添加客户端”均指适用于该协议的客户端管理流程。[入站表单](https://github.com/MHSanaei/3x-ui/blob/v3.10.2/frontend/src/pages/inbounds/form/InboundFormModal.tsx)、[客户端表单](https://github.com/MHSanaei/3x-ui/blob/v3.10.2/frontend/src/pages/clients/ClientFormModal.tsx)

### 监听地址与端口

| 字段 | 本文的处理方式 | 容易混淆的地方 |
| --- | --- | --- |
| 备注 | 写能识别用途的名称，如 `VLESS-REALITY` | 不参与协议认证 |
| 监听 IP | 对外提供 IPv4 服务的示例填 `0.0.0.0` | 这是服务器绑定地址，不是客户端连接地址 |
| 监听 IP 为 `127.0.0.1` | 只供本机使用或作为本机代理的后端 | 外部电脑不能直接访问服务器的回环监听 |
| 端口 | 使用本节对应的未占用端口 | 面板管理端口与节点端口分开 |
| 启用 | 开启准备使用的入站 | 保存记录不代表记录已经启用 |
| 分享地址策略 | 公网示例有此选项时选自定义，填写真实服务器地址或 `node.example.com` | 只影响导出地址，不改变实际监听或 DNS 解析 |
| 流量 / 到期 / 周期重置 | 首次测试不设限额和到期，不启用自动重置 | 入站限制和用户限制都可能阻止连接 |
| 排除订阅 | 需要用户从订阅取得此入站时保持关闭 | 不决定节点是否监听 |

`0.0.0.0` 不能填作客户端服务器地址。客户端填写真实服务器 IP，或解析到服务器的域名；自定义分享地址只填主机名或 IP，不带 `https://`、端口或路径。回环与 SSH 示例按各节手填本地转发入口，不导入错误的公网地址。IPv6 是否监听、是否能从客户端到达，也要单独核对，不能从 IPv4 结果推断。

### 客户端认证与限制

多用户协议保存入站后，进入“客户端 → 添加”，填写唯一 Email，在“关联入站”中选中刚创建的记录，再进入凭据设置。确认用户处于启用状态。不同协议的认证字段不同：

| 字段 | 作用与填写方式 |
| --- | --- |
| Email / 用户标识 | 使用能区分用户的唯一名称，例如 `phone-reality`，不要求真实邮箱 |
| UUID / ID | VLESS、VMess 等协议的身份凭据，使用面板生成值 |
| Password / Auth / Secret | 按对应协议生成，不与面板登录密码共用 |
| Flow | 属于 VLESS 客户端参数，按具体组合配置 |
| 流量配额 | 检查是否已耗尽；有限额时确认单位和重置方式 |
| 到期时间 | 检查是否已经到期，续期设置不等于当前记录一定有效 |
| IP 限制 | 有明确需求再设置，执行依赖相应机制；不要只改一个数就假定限制已生效 |
| Sub ID | 订阅标识，分享订阅会暴露连接配置，应按凭据保管 |

这些限制会影响节点能否使用，但不会修正错误的端口、公钥或证书。[3x-ui 客户端字段](https://github.com/MHSanaei/3x-ui/blob/v3.10.2/docs/content/docs/en/config/clients.mdx)

首次测试为每一类方案新建独立用户，避免修改共享密码或 Flow 时影响其他入站。本文的 VLESS 示例按下面的对应关系填写；这些示例都不启用额外 VLESS Encryption：

| 配置组合 | 客户端 Flow | 入站 Disable Flow |
| --- | --- | --- |
| RAW + REALITY + Vision | `xtls-rprx-vision` | 关闭 |
| RAW + TLS + Vision | `xtls-rprx-vision` | 关闭 |
| WS / gRPC / HTTPUpgrade / XHTTP 基础示例 | 空 | 开启，确保导出时为空 |
| 回环 VLESS + RAW + none 练习 | 空 | 保持 Flow 为空 |

Flow 属于客户端凭据，Disable Flow 是入站对 Flow 的处理选项。关联多个入站时，保存后还要检查每条导出配置，而不只看用户表单里显示的值。

### Sniffing 和高级选项

Sniffing 用来识别流量中的域名等信息，供路由使用。它不能代替 UUID 认证，也不能解决底层握手失败。没有基于嗅探的路由需求时，先保留当前默认值；启用后，再核对是否覆盖目标地址、是否只用于路由。[Xray 入站与嗅探字段](https://xtls.github.io/config/inbound.html)

`Accept PROXY Protocol` 仅在前置代理确实发送 PROXY 协议时启用。直连客户端没有这个头，不能为了“保留真实 IP”随意开启。Fallback、透明代理、接口绑定、mark 和自定义 sockopt 也先不改；后续每次调整都要能说明对应的网络需求。

## VLESS + TCP（RAW）+ REALITY + XTLS-Vision 配置

这一节使用 `VLESS + TCP/RAW + REALITY + XTLS-Vision`。先完成这一组，不同时叠加 WebSocket、XHTTP 或额外的 VLESS Encryption。

### 服务端填写

在面板中依次完成：

1.  进入入站列表并选择添加，在基础设置中填备注、VLESS、`0.0.0.0` 和 `24443`；分享地址使用真实服务器地址，本例不启用 Disable Flow。
2.  协议设置中的 Decryption、Encryption 使用 `none`，不生成额外 VLESS Encryption。
3.  传输选择 RAW，Header 使用 none；直连时不开 Accept PROXY Protocol。
4.  安全选择 REALITY，填写 Target 和 Server Names，再为这条入站生成密钥与 Short IDs。
5.  保存入站并检查核心状态。进入客户端管理，创建并关联该入站，生成 UUID、启用用户，Flow 选 `xtls-rprx-vision`，再保存用户。
6.  从该用户对应的分享链接或二维码导入客户端，按下表核对实际保存值，再发起请求。

字段对照如下：

| 字段 | 填写内容 |
| --- | --- |
| 备注 | `VLESS-REALITY` |
| 协议 | VLESS |
| 监听 IP / 端口 | `0.0.0.0` / `24443` |
| 客户端 | 生成 UUID，用户标识使用 `phone-reality`，并启用 |
| Flow | 在这个客户端记录中选择 `xtls-rprx-vision` |
| VLESS Encryption / Decryption | 本例不启用额外加密，使用 `none` |
| 传输 | TCP 或 RAW，按版本中的名称选择 |
| Header 类型 | `none` |
| 安全 | REALITY |
| Target / Dest | 符合 REALITY 条件、服务器可达的 TLS 目标，例如 `www.microsoft.com:443` |
| Server Names | 与目标证书匹配的名称，例如 `www.microsoft.com` |
| 私钥与公钥 | 点击面板生成按钮，保存这组对应关系 |
| Short IDs | 使用面板生成值，客户端使用其中一个 |
| SpiderX | 沿用生成值或默认值，如 `/` |
| 客户端 Fingerprint | 使用双方支持的指纹，如 `chrome` |

其他字段先保留基础设置：Show 关闭，Xver 使用 `0`，未设计版本限制时 Min/Max Client Ver 保持未限制状态，Max Time Diff 沿用默认。本例不启用 ML-DSA-65 等扩展认证，便于先验证基础握手。

目标站应按 REALITY 要求核对 TLS 能力、证书和可达性，不是任何域名填进去都能用。可以先从服务器检查候选站：

```bash
openssl s_client -connect www.microsoft.com:443 \
  -servername www.microsoft.com -tls1_3 -alpn h2 </dev/null
```

关注证书验证结果、协商的 TLS 版本和 ALPN。一次探测通过只是候选目标检查，不保证目标长期不变，也不保证整个代理配置正确。[REALITY 项目说明](https://github.com/XTLS/REALITY)、[3x-ui REALITY 字段](https://github.com/MHSanaei/3x-ui/blob/v3.10.2/docs/content/docs/en/config/reality.mdx)

### 客户端对应关系

保存后，从该客户端记录复制分享链接或二维码，导入兼容的客户端。检查实际导入值：

| 客户端字段 | 应与什么对应 |
| --- | --- |
| 服务器地址 | 你的真实服务器地址，示意为 `203.0.113.10` |
| 端口 | `24443` |
| UUID | 上面生成的客户端 UUID |
| 传输、安全 | TCP/RAW、REALITY |
| Flow | `xtls-rprx-vision` |
| SNI | 示例目标的 `www.microsoft.com`，不是本例服务器 IP |
| Public Key / Password | 当前客户端界面中对应的 REALITY 公钥参数；名称可能随核心变化 |
| Short ID | 服务端 Short IDs 中的一个 |
| 指纹 | 当前客户端核心支持的值 |

服务端 REALITY 私钥不填进客户端。连接地址负责找到你的服务器，SNI 参与握手，二者承担不同任务。[Xray REALITY 配置](https://xtls.github.io/config/transports/reality.html)

### 保存后的检查

在服务器检查 TCP 24443 是否由预期进程监听，再检查实际网络规则。从客户端发起真实代理请求，核对两端同一时段日志。

密钥正确却握手失败时，再核对两端核心和指纹是否支持实际握手。最低客户端版本是准入条件，清空它不能补齐旧核心缺少的能力；同名 App 在不同设备上也可能带有不同核心。[REALITY 版本与握手要求](https://github.com/MHSanaei/3x-ui/blob/v3.10.2/docs/content/docs/en/config/reality.mdx)

## Shadowsocks 配置（传统 AEAD 与 SS2022）

Shadowsocks 自身有协议加密。普通客户端通常使用原生 Shadowsocks 连接，不需要额外添加 REALITY 或 WebSocket；要使用额外封装，必须先确认两端实现支持同一方案。

### 传统 AEAD 配置

1.  在入站列表添加记录，备注填 `SS-AEAD`，协议选 `shadowsocks`，监听 `0.0.0.0`，端口先用 `24447`。
2.  进入协议设置，Method 选择 `aes-256-gcm`，Network 按需要选 TCP 或 TCP, UDP；`ivCheck` 保留默认。
3.  原生示例不叠加额外传输封装，传输使用 RAW、外层安全 none，保存入站。
4.  在客户端管理添加 `phone-ss`，关联刚才的入站，在密码字段生成独立密码并保存，再导出这个用户的配置。

| 字段 | 示例配置 |
| --- | --- |
| 协议 | Shadowsocks |
| 监听和端口 | `0.0.0.0:24447` |
| 加密方法 | 本例 `aes-256-gcm`，必须与客户端一致 |
| 客户端密码 | 独立生成强密码 |
| 网络 | 需要 TCP 和原生 UDP 时选择对应的 `tcp,udp` |
| 外层安全 | 原生连接不额外启用 TLS/REALITY |

客户端填写服务器地址、`24447`、同一加密方法和对应用户密码。使用面板的多用户配置时，检查最终导出的是这个用户的凭据，而不是只复制了入站中另一项密码。

### Shadowsocks 2022 配置

保留传统 AEAD 入站时，在另一个未占用端口，例如 `24462`，新增 `SS2022` 入站。协议仍选 shadowsocks，Method 改为 `2022-blake3-aes-128-gcm`；此时入站协议表单会显示服务器 Password。使用重新生成按钮生成服务器密钥，保存入站后再创建并关联独立用户，检查用户密码也是对应方法要求的密钥。

它使用规定长度的 Base64 密钥，不能用随手输入的普通短密码代替。客户端填写 `24462`，导入后同时核对方法和完整密码；不要继续选中端口为 `24447` 的旧 AEAD 节点。

以 AES-128 方案为例，需要手动生成时，可以分别运行下面命令生成服务器密钥和用户密钥：

```bash
openssl rand -base64 16
openssl rand -base64 16
```

两次输出是两个不同的值，分别填入面板对应位置。AES-256 方案使用相应的 32 字节密钥。不要把数字 16 理解为“Base64 文本必须只有 16 个字符”。

Xray 的 SS2022 多用户配置同时使用服务器密码和用户密码，客户端密码需要相应的 `服务器密钥:用户密钥` 组合。优先导入面板生成的完整分享链接；如果手填，核对客户端要求的字段和组合方式。[Shadowsocks 方法、密钥长度和多用户规则](https://xtls.github.io/config/inbounds/shadowsocks.html)

SS2022 的方法名称包含 `2022`，客户端也必须支持该方法。这个版本的多用户入站不提供 `2022-blake3-chacha20-poly1305`；传统 AEAD 示例也按表单实际提供的 `aes-256-gcm` 填写。[面板 SS 方法列表](https://github.com/MHSanaei/3x-ui/blob/v3.10.2/frontend/src/schemas/protocols/shared/shadowsocks.ts)

### TCP 与 UDP 分别验证

TCP 代理网页成功不等于原生 UDP 也可用。启用原生 UDP 时，检查 UDP 监听和规则，并使用确实产生 UDP 请求的应用验证；某些客户端会把 UDP 包装到其他传输里，判断时要看实际连接方式。

修改加密方法、服务器密钥或用户密钥后，重新导出客户端配置。旧分享链接不会自动跟着变。

## VLESS + TCP 本机练习（SSH 转发）

如果想先理解 UUID、监听端口和客户端导入，可以建一个仅供本机访问的 VLESS 入站，再经 SSH 转发连接。它用于把协议配置与 TLS/REALITY 拆开观察。

在基础页选 VLESS，填下面的监听与端口；协议页保持加解密 none，传输页 RAW/Header none，安全页 none。保存入站后创建关联用户 `local-vless`，生成 UUID，Flow 留空，再保存用户。然后建立 SSH 转发。

| 服务端字段 | 本机练习填写 |
| --- | --- |
| 协议、监听、端口 | VLESS、`127.0.0.1`、`24460` |
| 客户端 | 新生成 UUID，标识如 `local-vless`，并启用 |
| VLESS Encryption / Decryption | 本例不启用额外加密，使用 `none` |
| Flow | 留空 |
| 传输、Header | TCP/RAW、`none` |
| 外层安全 | `none`；仅在本例回环与 SSH 的边界内使用 |

保存后，在自己的电脑建立转发。先确认本地 `18081` 未被占用，并替换 SSH 账号、服务器地址与实际 SSH 端口：

```bash
ssh -N -L 127.0.0.1:18081:127.0.0.1:24460 admin@203.0.113.10
```

保持 SSH 会话，在代理客户端添加 VLESS，地址填电脑上的 `127.0.0.1`，端口填 `18081`，UUID 与服务端相同；传输为 TCP/RAW、外层安全为 none、Flow 为空。

```text
代理客户端 → 电脑本地 18081 → SSH 转发 → 服务器回环 24460 → VLESS
```

这一次不能直接沿用面板里仍指向公网地址和 `24460` 的分享链接；客户端连接的是电脑上的转发入口。选中这条记录后，用后文的本地 SOCKS 请求验证。

关闭 SSH 后，转发入口就不再可用。不要为了绕过这一步，把服务端改成公网监听后继续保留这套无额外加密的 VLESS 配置。对外使用回到完整的 REALITY 等方案，并一起核对 VLESS 的安全条件。[VLESS 配置条件](https://xtls.github.io/config/inbounds/vless.html)

## VMess + TCP 配置

VMess 本身有协议加密。下面使用 RAW 传输，不添加外层 TLS；不要把“外层安全 none”误读成关闭 VMess 自身的加密。单独新增入站：

1.  添加 `VMess-TCP`，基础页选择 `vmess`，监听 `0.0.0.0`，端口 `24461`。
2.  传输选 RAW，Header none，安全 none，保存。这里的 none 指外层安全，不是要求关闭 VMess 自身的协议加密。
3.  到客户端管理新增 `phone-vmess-tcp`，关联这一入站，生成 UUID；VMess Security 使用兼容的 `auto`，Alter ID 使用当前 AEAD 配置的 `0`。
4.  保存用户后导入对应配置，检查 UUID、TCP、端口、协议加密以及外层 TLS 关闭，再验证实际请求。

| 字段 | 服务端 | 客户端 |
| --- | --- | --- |
| 地址、端口 | 对外监听，示例端口 `24461` | 真实服务器地址、`24461` |
| 协议与用户 | VMess，新生成 UUID 并启用 | VMess、同一 UUID |
| 传输 | TCP/RAW；未设计额外头时使用 none | 对应 TCP/RAW |
| 外层 TLS | 这一对照方案不启用 | 对应关闭，不填写 REALITY 公钥 |
| 协议加密、Alter ID | 用户凭据中使用兼容的 `auto`、`0` | 使用相同的现代 AEAD 配置，不选 none |
| 时间 | 核对服务器实际时间 | 同时核对客户端设备时间 |

这组没有 WS 路径、SNI 或 Vision Flow。客户端若仍保留上一条节点的 TLS 或 WebSocket 字段，先清理与本方案无关的设置。

保存后核对 TCP `24461` 的监听、认证日志和真实请求。需要常规 TLS 入口时，再使用后文独立的 VMess/WS/TLS 方案，不在一条记录中混用两组参数。[VMess 协议配置](https://xtls.github.io/config/inbounds/vmess.html)

## TLS 入站的证书准备与填写

前面的 REALITY 基础方案不需要准备本节的节点证书。接下来的 VLESS/TLS、XHTTP/TLS、WebSocket/TLS、Trojan/TLS、Hysteria2 和 TUIC 等示例，需要提前准备可验证的证书。

以自己控制的 `node.example.com` 为例，先完成解析和证书申请。直连示例中，域名解析到节点服务器；有 AAAA 记录时也检查对应的 IPv6。这里的域名不是 REALITY 借用的目标站域名。

检查前确认服务器可以运行 `openssl`。Debian 上如果没有安装，可先执行 `sudo apt install openssl`。随后检查证书文件：

```bash
sudo openssl x509 -in /etc/x-ui/certs/node.example.com/fullchain.pem \
  -noout -subject -issuer -dates -ext subjectAltName
```

这条路径只是示例。用实际证书路径运行，确认有效期、颁发者，以及 SAN 是否覆盖客户端将要验证的主机名。[OpenSSL 证书查看选项](https://docs.openssl.org/3.0/man1/openssl-x509/)

在入站编辑器的安全页选 TLS，添加或展开证书记录，选择“证书路径”模式，然后分别填写证书链文件和私钥文件。若选“证书内容”，对应框需要完整 PEM 内容，不能再粘贴文件路径。表单里证书一栏可能译作“公钥”，这里填写的是证书链，并非 REALITY 的 Public Key。

| 填写位置 | 字段 | 示例或要求 |
| --- | --- | --- |
| 服务端入站 | 证书链 | `/etc/x-ui/certs/node.example.com/fullchain.pem`，替换为实际文件 |
| 服务端入站 | 证书私钥 | `/etc/x-ui/certs/node.example.com/privkey.pem`，与证书匹配 |
| 客户端节点 | SNI / Server Name | 验证的主机名，例如 `node.example.com`，应在证书 SAN 中 |
| 客户端节点 | Allow insecure / 跳过证书验证 | 保持关闭 |
| 两端按需对应 | ALPN | 按传输要求设置，不能把所有协议统一改成 `http/1.1` |

“使用面板证书”按钮会带入已有路径，不负责申请证书；使用前确认它覆盖节点的 SNI，且节点服务进程能够读取。Docker 部署填写容器内挂载路径，不能直接照抄宿主机路径。

TLS 版本、密码套件、ECH、证书固定等高级项先保留默认。续期后确认新文件已部署，并按服务实际加载方式更新证书。[Xray TLS 字段](https://xtls.github.io/config/transports/tls.html)

## VLESS + TCP + TLS + XTLS-Vision 配置

已有节点证书时，也可以用 RAW/TLS 承载 VLESS，端口单独用 `24463`。

1.  添加 `VLESS-TCP-TLS`，监听 `0.0.0.0`、端口 `24463`；协议页 Decryption 和 Encryption 均为 none。
2.  传输选 RAW，Header none；安全选 TLS，按上一节填实际证书链和私钥。
3.  保存后新增关联用户 `phone-vless-tls`，生成 UUID。这个 RAW/TLS 示例使用 `xtls-rprx-vision`，入站不启用 Disable Flow。
4.  客户端填写真实节点域名、`24463`、UUID、TCP/RAW、TLS、证书覆盖的 SNI 和相同 Flow；证书验证开启。
5.  检查 TCP 监听与 TLS，再发起代理请求。这里不填写 REALITY Target、Public Key 或 Short ID。

若实际客户端不支持 Vision，应另行核对普通 VLESS/TLS 的两端 Flow 设置，不只删除客户端一侧的字段。[VLESS 与 Flow](https://xtls.github.io/config/inbounds/vless.html)

## VLESS + WebSocket + TLS 配置

这套示例由节点自己终止 TLS，配置顺序为：

1.  新增 VLESS 入站，对外监听使用未占用的 TCP `24457`。
2.  协议页额外 VLESS Encryption 使用 none；本例在基础页启用 Disable Flow，确保导出的 Flow 为空。
3.  传输选 WebSocket，Path 填 `/vless-ws`，不需要额外覆盖时将 Host 和自定义头留空。
4.  安全选 TLS，填节点实际证书链与私钥；客户端验证的 SNI 使用证书覆盖的 `node.example.com`。
5.  保存入站后新增启用的客户端并关联此入站，生成 UUID，Flow 留空。保存用户后导出链接，核对客户端地址、`24457`、UUID、WS、路径、TLS 和 SNI，再检查真实请求。客户端不填写 REALITY 公钥或 Short ID。

三个 HTTP 类传输的差异可以先对照下表，gRPC 与 HTTPUpgrade 的具体操作在后面分别说明：

| 传输 | 示例端口 | 服务端填写 | 客户端需要对应 |
| --- | --- | --- | --- |
| WebSocket | 24457/TCP | Path 为 `/vless-ws`；不需要额外头时留空 | WS、相同路径、TLS、证书对应的 SNI |
| gRPC | 24458/TCP | Service Name 为 `vless-grpc`；不用额外覆盖时 Authority 留空 | gRPC、相同 Service Name、TLS；ALPN 支持 `h2` |
| HTTPUpgrade | 24459/TCP | Path 为 `/vless-upgrade` | HTTPUpgrade、相同路径、TLS、SNI |

WebSocket 的 `/vless-ws` 是节点请求路径，不是面板的 Web Base Path。gRPC 的基础 Service Name 示例不在前面自行加 `/`；有意使用自定义 gRPC 路径时，再按核心文档配置。HTTPUpgrade 也不能仅靠改一个路径就当作 WebSocket 导入。[WebSocket 字段](https://xtls.github.io/config/transports/websocket.html)、[gRPC 字段](https://xtls.github.io/config/transports/grpc.html)、[面板传输选项](https://github.com/MHSanaei/3x-ui/blob/v3.10.2/docs/content/docs/en/config/transports.mdx)

需要 Nginx 时，先明确 TLS 在哪里终止：客户端到 Nginx 使用 TLS、Nginx 到本机后端使用明文，是一套配置；后端自己继续使用 TLS，又是另一套。外部端口、后端端口、路径和上游协议都要对应，不能同时在同一个地址和 TCP 端口启动两个独立监听器。

需要 CDN 时，再核对服务商允许的端口、传输、HTTP 版本和超时。本文的 `244xx` 端口是直连示例，并不自动适用于普通 CDN 代理。REALITY 直连也不能直接套成普通 HTTPS CDN 配置。

## VLESS + gRPC + TLS 配置

1.  新增 `VLESS-gRPC-TLS`，监听 `0.0.0.0`、端口 `24458`，分享地址填写实际节点域名；启用 Disable Flow。
2.  协议页加解密 none。传输选 gRPC，Service Name 填 `vless-grpc`，Authority 留空，Multi Mode 先保持关闭。
3.  安全选 TLS，填节点证书链和私钥，ALPN 支持 `h2`；保存入站。
4.  新增并关联用户 `phone-grpc`，生成 UUID，Flow 为空，保存后导入配置。
5.  客户端选 gRPC、TLS，填端口 `24458`、相同 Service Name、UUID、节点 SNI；证书验证开启。支持该字段的客户端把 Multi Mode 与服务端对应。

先检查 TLS 是否协商出适用的 HTTP/2，再用代理客户端认证并访问。TLS 正常但请求失败时，核对 Service Name 是否误加 `/`、客户端是否仍使用 WS，以及反向代理是否使用 gRPC 上游。[gRPC 表单](https://github.com/MHSanaei/3x-ui/blob/v3.10.2/frontend/src/pages/inbounds/form/transport/grpc.tsx)

## VLESS + HTTPUpgrade + TLS 配置

1.  新增 `VLESS-HTTPUpgrade-TLS`，监听 `0.0.0.0`、端口 `24459`，启用 Disable Flow，协议页加解密 none。
2.  传输选 HTTPUpgrade，Path 填 `/vless-upgrade`；直连不额外覆盖 Host、Headers，Accept PROXY Protocol 关闭。
3.  安全选 TLS，填实际节点证书链与私钥，保存入站。
4.  新增关联用户 `phone-upgrade`，生成 UUID，Flow 留空，保存后导出。
5.  客户端填写 HTTPUpgrade、相同路径、端口 `24459`、UUID、TLS 和节点 SNI，完成真实请求验证。

HTTPUpgrade 和 WebSocket 的协议处理不同；客户端没有 HTTPUpgrade 选项时，不能改选 WS 代替。排查时也别把节点 Path 填成面板管理路径。[HTTPUpgrade 表单](https://github.com/MHSanaei/3x-ui/blob/v3.10.2/frontend/src/pages/inbounds/form/transport/httpupgrade.tsx)

## VLESS + XHTTP 配置（TLS / REALITY）

XHTTP 可以分别搭配 TLS 或 REALITY。先配置使用自己域名和证书的直连 TLS 方案，再看 REALITY 方案需要替换哪些字段；两种方案使用独立入站和用户。

### TLS 方案的服务端配置

1.  新增 `VLESS-XHTTP-TLS`，基础页选 VLESS，监听 `0.0.0.0`、端口 `24444`，分享地址填实际节点域名；启用 Disable Flow。
2.  协议页加解密 none；传输页选 XHTTP，Path 填 `/vless-xhttp`，Mode 选当前版本支持的 auto，Host 不额外覆盖。
3.  安全页选 TLS，填写证书链和私钥，保存入站。
4.  新增关联用户 `phone-xhttp`，生成 UUID，Flow 为空，保存用户后导出配置。

| 字段 | 填写内容 |
| --- | --- |
| 协议、端口 | VLESS、`24444` |
| 监听 | `0.0.0.0` |
| 客户端 UUID | 单独生成，标识如 `phone-xhttp` |
| VLESS Encryption / Decryption | 本例为 `none` |
| Flow | 本例留空，不使用经典 TCP Vision 的 Flow |
| 传输 | XHTTP |
| Path | `/vless-xhttp` |
| Host | 直连时先不额外覆盖；客户端如需要填写，使用实际节点域名 |
| Mode | 从面板与核心支持的默认 `auto` 开始 |
| 安全 | TLS |
| 证书和私钥 | 实际节点证书文件 |
| SNI | 客户端验证的 `node.example.com` |

本例没有 REALITY 目标、公钥和 Short ID。XHTTP 的分块、padding、缓冲、会话标识和 xmux 等参数先保留默认值，不同时复制多个来源的调优方案。`auto` 代表使用核心的协商或默认行为，不代表所有旧客户端都支持 XHTTP。[XHTTP 官方说明](https://xtls.github.io/config/transports/splithttp.html)

### TLS 方案的客户端配置与验证

客户端导入后，对照服务器地址 `node.example.com`、端口 `24444`、UUID、XHTTP、TLS、路径 `/vless-xhttp` 和 SNI。核对本例 Flow 为空，证书验证开启。

先验证 TLS 入口：

```bash
openssl s_client -connect node.example.com:24444 \
  -servername node.example.com -verify_hostname node.example.com \
  -verify_return_error </dev/null
```

证书验证失败时先解决证书链、有效期或主机名问题。TLS 通过后，再在客户端发起代理请求；上面的命令没有携带 VLESS 认证，不能证明节点已经可用。

如果核心日志不识别 XHTTP，先核对核心版本和实际生成配置。若只是某一导入方式丢了路径或模式，比较客户端保存的值，不要反复重签证书。

### REALITY 方案的配置差异

这组不使用自己的节点 TLS 证书，改用 REALITY 的目标与密钥。单独创建 `VLESS-XHTTP-REALITY`：

1.  基础页选 VLESS，监听 `0.0.0.0`、端口 `24465`，分享地址填实际服务器地址，启用 Disable Flow。
2.  协议页 Decryption、Encryption 均为 none；传输选 XHTTP，Path 填 `/vless-xhttp-reality`，Mode 使用 auto。
3.  安全选 REALITY，填已经从服务器检查过的 Target 与匹配的 Server Names，例如 `www.microsoft.com:443` 和 `www.microsoft.com`；生成本入站的密钥对与 Short IDs，客户端指纹选择双方支持的 chrome。
4.  保存入站后新增关联用户 `phone-xhttp-reality`，生成独立 UUID，Flow 为空，再保存用户。
5.  导入后核对 `24465`、UUID、XHTTP 路径、REALITY、公钥、Short ID、SNI 和指纹，先检查 TCP 监听，再验证实际代理请求。

两种方案的关键差异如下：

| 项目 | XHTTP/TLS | XHTTP/REALITY |
| --- | --- | --- |
| Path / Mode | `/vless-xhttp` / auto | 可用 `/vless-xhttp-reality` / auto，两端对应 |
| 安全 | TLS | REALITY |
| 服务端身份材料 | 自己的证书链、私钥 | REALITY 对应密钥、Short IDs、合适的 Target 和 Server Names |
| 客户端 SNI | 节点证书覆盖的名称 | REALITY Server Names 中匹配目标的一项 |
| 客户端额外字段 | 验证节点证书 | 对应公钥、Short ID、指纹 |
| 本例 Flow | 空 | 空；不因 REALITY 就套用 RAW 的 Vision Flow |

客户端连接地址仍是自己的服务器，REALITY SNI 对应目标站。导入时同时确认核心支持 XHTTP 和 REALITY，Flow 保持本例的空值。[面板能力条件](https://github.com/MHSanaei/3x-ui/blob/v3.10.2/frontend/src/lib/xray/protocol-capabilities.ts)

## VMess + WebSocket + TLS 配置

VMess 的身份认证使用 UUID。下面创建一条 WS/TLS 入站，复用证书准备步骤，但使用独立的端口、路径和用户。

### 服务端填写

1.  添加 `VMess-WS-TLS`，监听 `0.0.0.0`、端口 `24445`，分享地址填实际节点域名。
2.  传输选 WebSocket，Path `/vmess-ws`；安全选 TLS，填写实际证书链与私钥，保存入站。
3.  新增关联用户 `phone-vmess`，生成 UUID，VMess Security 用兼容的 auto、Alter ID 为 0，启用并保存。
4.  导出该用户在 `VMess-WS-TLS` 下的配置；不要误复制前面 VMess/TCP 入站的链接。

| 字段 | 填写内容 |
| --- | --- |
| 备注、协议 | `VMess-WS-TLS`、VMess |
| 监听、端口 | `0.0.0.0`、`24445` |
| 客户端 | 新生成 UUID，标识如 `phone-vmess`，确认启用 |
| 传输 | WebSocket |
| Path | `/vmess-ws` |
| Host / 额外请求头 | 本例不添加额外覆盖 |
| 安全 | TLS |
| 证书和私钥 | 自己的节点证书，覆盖 `node.example.com` |

### 客户端填写与验证

导入后核对 `node.example.com:24445`、UUID、WebSocket、路径 `/vmess-ws`、TLS 和 SNI。VMess 的协议加密设置与外层 TLS 不同，使用当前客户端支持的协议设置；这里不用 VLESS 的 Vision Flow，也没有 REALITY 公钥。

在 TLS 和路径之外，VMess 认证还依赖两端时间。服务器上可以先查看：

```bash
timedatectl status
```

检查实际 UTC 时间和同步状态，客户端设备也要核对。改时区不会自动修复绝对时间偏差；已有时间同步服务时，先排查它，不要重复安装多个互相竞争的同步服务。[VMess 身份和时间要求](https://xtls.github.io/config/inbounds/vmess.html)

保存后验证监听、TLS 和客户端真实请求。若客户端导入后路径为空，先修正导入结果；若 TLS 正常而认证失败，再看 UUID、时间和两端日志。

## Trojan + TCP + TLS 配置

Trojan 这一组用密码认证，并使用自己的 TLS 证书。它与面板登录账号无关。

1.  新增 `Trojan-TLS`，协议选 trojan，监听 `0.0.0.0`、端口 `24446`，分享地址填实际节点域名。
2.  传输选 RAW/Header none；安全选 TLS，填节点证书链和私钥。Fallback 本例留空，保存入站。
3.  新增并关联用户 `phone-trojan`，在密码字段生成独立密码，启用并保存。使用的是这个用户的 Password。
4.  导入用户的 Trojan 配置，核对 TLS、SNI、端口和密码，并按下文所述核对当前核心的客户端 Mux 要求。

| 服务端字段 | 填写内容 |
| --- | --- |
| 协议、端口 | Trojan、`24446` |
| 监听 | `0.0.0.0` |
| 客户端标识 | 如 `phone-trojan` |
| Password | 生成独立的随机强密码 |
| 传输与 Header | TCP/RAW、`none` |
| 安全 | TLS |
| 证书和私钥 | 实际节点证书文件 |
| Fallback | 这一基础方案先不配置 |

客户端填写服务器地址 `node.example.com`、端口 `24446`、对应密码、TCP/RAW、TLS，以及证书覆盖的 SNI；保持证书验证开启。不要填写 VLESS UUID、Short ID 或 REALITY 公钥。

当前 Xray Trojan 文档还对公网使用提出了 Mux 要求，涉及内层 TLS 流量特征。按所用核心的要求启用兼容的客户端 Mux，并确认该客户端与服务端实现对应；不同客户端里名字相近的多路复用开关不能直接视为同一种实现。[Trojan 官方配置与使用条件](https://xtls.github.io/config/inbounds/trojan.html)

检查顺序仍是监听、TLS、认证、真实请求。TLS 验证通过而随后被关闭时，对照密码和核心日志。浏览器直接打开这个端口得到空响应或错误页，也不能据此判断 Trojan 认证是否正常。

## Hysteria2 配置

Hysteria2 使用基于 QUIC 的传输。先确认服务商和客户端网络允许 UDP，并准备节点证书；只放行 TCP 不足以完成连接。

### 服务端填写

1.  添加 `Hysteria2`，基础协议选 `hysteria`，监听 `0.0.0.0`、端口 `24448`，分享地址填实际节点域名。
2.  传输页使用专用 Hysteria 表单，版本 2 在本版中固定，不需要寻找单独的 TCP/WS 选项。UDP Idle Timeout 先沿用默认，Masquerade 首次测试关闭。
3.  安全页使用 TLS，填写实际节点证书链和私钥；首次测试不启用 UDP Hop、FinalMask 或额外 QUIC 调优，保存入站。
4.  新增关联用户 `phone-hy2`，在 Hysteria Auth 字段生成认证值，启用并保存。这里对应 Auth，不把通用 Password 当成已生效的 Hysteria 凭据。
5.  导入该用户的 `hysteria2://` 配置，检查服务器、端口、Auth、SNI 和证书验证，再用实际 UDP 连接测试。

| 字段 | 填写内容 |
| --- | --- |
| 协议 | Hysteria / Hysteria2，按界面名称 |
| 版本 | `2` |
| 监听和端口 | 对外监听、`24448` |
| 传输 | 对应的 Hysteria 传输 |
| 用户标识与 Auth | 如 `phone-hy2`，生成独立认证字符串 |
| TLS | 配置节点证书和私钥；本协议包含相应的 TLS 要求 |
| 客户端 SNI | 证书覆盖的 `node.example.com` |
| Masquerade | 有明确需求再设置，首次验证先不额外添加 |
| UDP 空闲超时、QUIC 和带宽参数 | 先保留当前版本默认值 |

需要 Masquerade 时，在传输页打开该项，再选类型：proxy 填实际可达的 HTTPS 上游 URL，file 填服务进程可读的目录，string 填状态码和响应正文。它处理未认证访问时的伪装响应，不替代用户 Auth，也不会替你申请节点证书。

认证用户需要配合 Hysteria 传输生效，不能只选择一个名为 Hysteria 的协议，再任意换成 TCP。带宽字段如需调整，先看单位和拥塞控制模式；不按服务器网卡标称速率随意填大数。[Xray Hysteria 用户与版本](https://xtls.github.io/config/inbounds/hysteria.html)

### 客户端填写与验证

从面板导入 `hysteria2://` 分享链接，或者在兼容客户端填写服务器 `node.example.com:24448`、Auth、SNI 和证书验证设置。不要导入旧版 Hysteria 配置后只改一个协议名称。

如果启用了 Salamander 等混淆，双方的类型、密码和实现能力必须对应；未启用时，客户端也不要额外加上。先检查：

```bash
sudo ss -lnup 'sport = :24448'
```

看到 UDP socket 只能证明本机监听。下一步用兼容客户端实际握手并发起请求；`Test-NetConnection -Port 24448` 测的是 TCP，不适合据此宣布 Hysteria2 节点失败或正常。

## TUIC v5 配置

TUIC 也需要 UDP 和 TLS，但认证字段与 Hysteria2 不同。在所参考的面板版本中，它由面板内的服务处理，再衔接 Xray 路由；检查进程时不能限定“必须看到一个独立 Xray 进程占用这个 UDP 端口”。

1.  新增 `TUIC-v5`，协议选 tuic，监听 `0.0.0.0`、端口 `24449`，设置正确的分享地址。
2.  进入 **协议** 页填写证书路径、私钥路径和节点 SNI。这里使用 TUIC 自己的表单，不寻找普通 RAW/TLS 传输组合；自动补全路径后仍需确认文件真实存在。
3.  本例拥塞控制选 bbr，ALPN 使用 h3，UDP Relay Mode 使用 native；高级设置保留默认，保存入站。
4.  新增并关联 `phone-tuic`，同时生成 UUID 和密码，启用并保存，再导出对应配置。
5.  客户端选 TUIC v5，核对两项凭据、`24449`、SNI、ALPN 与证书验证，然后检查 UDP 实际请求。

| 服务端字段 | 填写内容 |
| --- | --- |
| 协议、端口 | TUIC、`24449` |
| 证书、私钥 | 实际节点证书与私钥 |
| SNI | 客户端验证的 `node.example.com` |
| 客户端 | 唯一标识、UUID 和密码，使用面板生成值 |
| ALPN | 使用支持的默认值，如 `h3` |
| 拥塞控制 | 先沿用面板默认配置 |
| UDP Relay Mode | 先沿用导出配置，如 `native` |
| Zero-RTT | 首次验证沿用默认状态，不把它当作连接修复开关 |

保存后使用面板提供的分享链接或兼容的 YAML 配置导入。手工配置时，UUID 和密码都要填写；不能把 Hysteria2 的单个 Auth 原样当成全部 TUIC 凭据。

例如，面板导出到 Mihomo 的配置需要对应下面这些字段。替换凭据与域名后再合并到已有客户端配置，不把这段当成包含代理组和路由规则的完整文件：

```yaml
proxies:
  - name: TUIC-24449
    type: tuic
    server: node.example.com
    port: 24449
    uuid: "替换为面板生成的UUID"
    password: "替换为该客户端密码"
    sni: node.example.com
    alpn:
      - h3
    congestion-controller: bbr
    udp-relay-mode: native
    reduce-rtt: false
    skip-cert-verify: false
```

这里沿用官方导出示例中的基础参数；自己的服务端选择不同参数时，检查实际导出结果。保存后检查 UDP 24449、TLS 和真实请求，尤其不要只改客户端的证书忽略选项。[3x-ui TUIC 配置与导出说明](https://github.com/MHSanaei/3x-ui/blob/v3.10.2/docs/content/docs/en/config/tuic.mdx)

## WireGuard 配置

WireGuard 以密钥对和 Peer 建立隧道，不使用 VLESS UUID、SNI 或普通 TLS 证书。Xray 的 WireGuard 入站是用户态实现，配置方式与直接在系统中创建内核 WireGuard 网卡的教程有所区别。

### 服务端和 Peer

1.  新增 `WireGuard`，基础协议选 wireguard，监听 `0.0.0.0`、端口 `24450`，分享地址填实际服务器地址。
2.  在协议页生成或保留服务器密钥对。Subnet IP 填不冲突的 `172.20.0.0`，CIDR 填 `24`，MTU 先用表单默认；DNS 填自己的可用解析配置。
3.  `No Kernel TUN` 先保留默认，不额外选择 WS、TLS 或 REALITY，保存入站。
4.  在客户端管理新增 `phone-wg` 并关联此入站，生成客户端密钥对；核对分配的隧道地址及导出路由，例如当前用户分配到 `172.20.0.2/32`。需要 PSK 时用生成按钮，两端对应。
5.  保存后导出该用户的隧道配置，导入 WireGuard 客户端。后续用户必须分配不同地址，不能复制同一份私钥和隧道 IP。

新版面板通过客户端记录管理 Peer，通常不需要在入站中手工拼接整个 peers 数组。下表解释导出配置与底层字段的对应关系：

| 位置 | 填什么 |
| --- | --- |
| 服务端 Secret Key | 服务器私钥 |
| 服务端 Peer Public Key | 这个客户端的公钥 |
| 服务端 Peer Allowed IPs | 该客户端允许使用的隧道源地址，如 `172.20.0.2/32` |
| 客户端 Interface PrivateKey | 客户端私钥 |
| 客户端 Interface Address | 与分配地址一致，如 `172.20.0.2/32` |
| 客户端 Peer PublicKey | 服务器公钥 |
| 客户端 Peer Endpoint | 真实服务器地址和 UDP `24450` |
| 预共享密钥 | 如果使用，两端填写同一值；不使用则两端对应留空 |

多个服务端 Peer 的地址范围不能重叠。服务端 Peer 的 Allowed IPs 用于匹配该客户端的隧道源地址；客户端 Peer 的 AllowedIPs 则决定哪些目标流量进入隧道，含义不同。[Xray WireGuard 配置](https://xtls.github.io/config/inbounds/wireguard.html)

### 客户端配置示意

能从面板导出时，优先使用与当前 Peer 对应的配置。手动填写时，一份仅接管 IPv4 的示意如下：

```ini
[Interface]
PrivateKey = 替换为客户端私钥
Address = 172.20.0.2/32

[Peer]
PublicKey = 替换为服务器公钥
Endpoint = 203.0.113.10:24450
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25
```

这是待替换参数的示意文件。DNS 使用自己的有效配置；如果还要接管 IPv6，先配置相应隧道地址与出口，再增加对应路由，不能只添加 `::/0` 就假定 IPv6 可用。

连接后检查客户端最近握手和收发计数，再确认需要代理的目标流量确实进入隧道。仅握手有更新但网页打不开时，继续检查路由、DNS 和出站；不要直接套用另一份内核 WireGuard 教程添加一组 NAT 规则。

## AmneziaWG 配置

AmneziaWG 在 WireGuard 的基础上增加了混淆等参数，需要兼容的 Amnezia 客户端。所参考的 3x-ui 版本内置用户态服务，基础配置按面板生成值进行。

1.  新增 AmneziaWG 入站，设置 UDP `24451`。
2.  在协议页生成或保留服务器密钥，Subnet IP 使用不冲突的示意 `172.20.1.0`，CIDR 填 `24`，与前面的 WireGuard 分开。填自己的主、备用 DNS；未配置 IPv6 出口时先关闭 IPv6。
3.  保留面板生成的混淆参数，或使用重新生成按钮创建一套新参数。
4.  保存入站后，在客户端管理新增并关联 `phone-awg`，让面板生成独立密钥和分配隧道地址，启用并保存。
5.  下载该客户端 `.conf` 或使用支持的分享链接，导入兼容的 AmneziaWG/AmneziaVPN 客户端。

| 字段组 | 处理方式 |
| --- | --- |
| Subnet | 确认与宿主机、容器和其他隧道网络不冲突 |
| MTU | 先保留默认值，有实际证据再调整 |
| 客户端 DNS | 填确实可用的解析配置，检查它最终进入哪个网络路径 |
| Jc、Jmin/Jmax、S1/S2 等 | 使用同一套服务端生成参数，不从多份教程拼接 |
| H1–H4 | 保持有效且不重叠；手动修改前核对当前版本规则 |
| S3/S4、I1–I5 | 使用同一套面板生成值，确认客户端支持对应的 padding 和签名包参数 |
| Header Protection Key | 服务端生成时一并导出给客户端，不能只改一端 |
| Content Padding、握手计时范围 | 保持生成的整套范围，先不单独调优 |
| Random Trailers / Disable Cookies | 沿用本次生成配置，客户端需支持对应版本 |

外部接口没有特殊需求时沿用自动选择；手填时先用 `ip route` 确认实际出口，不能照抄别人的 `eth0`。需要给用户配置转发端口时，还要明确端口和 TCP/UDP 类型；基础示例先不添加。

修改服务端混淆参数后，重新导出所有受影响客户端；只更新服务端会使旧客户端继续发送另一套数据。该版本的客户端流量衔接 Xray 路由，不能把它直接视为系统中一张配置完全独立的内核隧道网卡。[AmneziaWG 配置与版本要求](https://github.com/MHSanaei/3x-ui/blob/v3.10.2/docs/content/docs/en/config/amneziawg.mdx)

## HTTP 代理配置

HTTP 代理适合给支持 HTTP 代理设置的程序提供入口。本例使用服务器回环监听，再通过 SSH 转发访问。

### 服务端填写

1.  添加 `HTTP-Local`，基础协议选 http，监听 `127.0.0.1`、端口 `24452`。
2.  在协议页的 Accounts 添加账号，User 例如 `proxyuser`，Pass 使用独立生成的密码，不能留一个空账号。
3.  Allow Transparent 关闭；本例没有普通传输、安全层选择步骤，连接保护由 SSH 提供，保存入站。
4.  该账号不是“客户端”页面的 Email；此协议直接使用 Accounts 中的用户名密码，不再另建 VLESS 式用户。

| 项目 | HTTP 示例 |
| --- | --- |
| 协议与用途 | HTTP，供 HTTP 代理及 CONNECT 使用 |
| 监听地址 / 端口 | `127.0.0.1:24452` |
| Accounts | 设置独立 User / Pass |
| Allow Transparent | 关闭 |
| 客户端连接位置 | 通过下文 SSH 转发后的电脑本地端口 |

HTTP 代理能通过 CONNECT 承载访问 HTTPS 网站的请求，不代表“客户端到代理这一段自动使用了 TLS”。如果改为公网使用，需要另行安排认证、加密与访问控制。[HTTP 代理说明](https://xtls.github.io/config/inbounds/http.html)、[SOCKS 代理说明](https://xtls.github.io/config/inbounds/socks.html)

### 从自己的电脑使用

以下假设 SSH 服务使用实际核对过的默认端口，账号 `admin` 也必须替换，并先确认电脑上的本地端口 `18080` 未被占用。只访问 HTTP 入口时，在自己的电脑建立一个转发：

```bash
ssh -N -L 127.0.0.1:18080:127.0.0.1:24452 admin@203.0.113.10
```

保持这个 SSH 连接，在另一个终端测试本地入口：

```bash
curl --noproxy "" --proxy http://127.0.0.1:18080 \
  --proxy-user proxyuser --connect-timeout 5 --max-time 20 \
  -o http-probe.html -w "HTTP %{http_code}\n" https://example.com/
```

把 `proxyuser` 换成入站实际用户名，按 curl 提示输入密码。检查 HTTP 状态与保存的 `http-probe.html`；认证失败时，回到入站 Accounts 核对账号。[代理认证选项](https://curl.se/docs/manpage.html#--proxy-user)

只在服务器本机调用代理时，直接使用服务器上的回环端口即可。连接后同时检查 HTTP 状态和返回内容，不把一个拒绝页当成代理成功。

## Mixed 代理配置（HTTP / SOCKS）

Mixed 在同一个监听端口接受 HTTP 与 SOCKS 连接。在这个面板版本中，想创建普通 SOCKS 入口，选择 mixed，再让应用按 SOCKS5 连接；不要寻找本版协议列表中不存在的独立 socks 项。

1.  添加 `Mixed-Local`，协议 mixed，监听 `127.0.0.1`，端口 `24453`。
2.  协议页 Accounts 添加账号，例如 User `mixeduser` 和独立 Pass；Auth 明确选择 password，不选 noauth。
3.  UDP 保持关闭，因此不额外填写 UDP IP；保存入站。它和 HTTP 一样使用入站内的 Accounts，不再创建另一套 UUID 用户。
4.  在自己的电脑建立独立的 TCP 转发，本地端口例如 `18082`：

```bash
ssh -N -L 127.0.0.1:18082:127.0.0.1:24453 admin@203.0.113.10
```

保持 SSH 连接，应用可以选择 HTTP 代理或 SOCKS5 代理，地址都是电脑上的 `127.0.0.1:18082`，用户名密码与 Mixed 的 Accounts 相同。例如按 SOCKS5 验证：

```bash
curl --noproxy "" --proxy socks5h://127.0.0.1:18082 \
  --proxy-user mixeduser --connect-timeout 5 --max-time 20 \
  -o mixed-probe.html -w "HTTP %{http_code}\n" https://example.com/
```

按提示输入对应密码，核对状态与返回文件。需要比较 HTTP 时，把代理 URL 改为 `http://127.0.0.1:18082`，保留同一套凭据。UDP Associate 需要另行设计实际 UDP 通路，普通 TCP SSH 转发不会自动转发 UDP。[Mixed 表单](https://github.com/MHSanaei/3x-ui/blob/v3.10.2/frontend/src/pages/inbounds/form/protocols/mixed.tsx)

## Tunnel 端口转发配置（旧称 dokodemo-door）

Tunnel 旧称 dokodemo-door，主要用于端口映射或流量重定向。两者是同一类功能的新旧名称；本例演示固定目标转发，没有 VLESS 那样的 UUID 认证，也不能作为 SOCKS 代理端口直接填入浏览器。

用一个仅在服务器本机开放的 TCP 转发示例理解字段：

1.  新增 `Tunnel-Local`，协议 tunnel，基础页监听 `127.0.0.1`、端口 `24454`。
2.  协议页 Rewrite Address 填 `example.com`，Rewrite Port 填 `443`，Allowed Network 选 TCP。
3.  Port Map 留空，Follow Redirect 关闭；传输页如有 sockopt，先保留默认。保存后不创建客户端账号。
4.  确认当前入站路由能使用可达目标的出站，在服务器本机运行后面的请求。

| 字段 | 配置 |
| --- | --- |
| 协议 | 本版选 `tunnel`，旧版名称为 `dokodemo-door` |
| 监听 IP / 端口 | `127.0.0.1:24454` |
| Rewrite Address | `example.com` |
| Rewrite Port | `443` |
| Allowed Network | TCP |
| Port Map | 留空，使用本例的统一目标 |
| Follow Redirect | 本例关闭，不接管透明代理流量 |
| 出站 | 确认当前路由选择可访问目标的出站 |

不同核心中目标字段可能显示为 address/port，或 rewriteAddress/rewritePort。按表单语义配置，不把不同版本的 JSON 字段混写。[Tunnel 配置](https://xtls.github.io/config/inbounds/tunnel.html)

在服务器上，把原本发往目标的 HTTPS 连接临时改拨到本机转发端口，同时保留目标主机名：

```bash
curl --noproxy '*' \
  --connect-to example.com:443:127.0.0.1:24454 \
  --connect-timeout 5 --max-time 20 -I https://example.com/
```

核对证书与 HTTP 响应，并结合日志确认请求确实通过这个转发。访问 `http://127.0.0.1:24454` 会向一个 TLS 目标发送明文 HTTP，不是同一个测试。

以后需要公开转发时，再明确允许的来源、目标服务自身认证，以及路由限制。不要把一个无额外用户认证的转发口当作已完成安全配置的通用代理。[curl connect-to](https://curl.se/docs/manpage.html#--connect-to)

## MTProto 配置

MTProto 入站用于 Telegram 代理。这里使用所参考版本管理的 MTProto 服务，不把它当作普通 Xray VLESS 入站。

1.  新增 MTProto 入站，设置准备对外提供服务的监听地址和 TCP `24455`。
2.  协议页设置 Fake TLS Domain，例如 `www.cloudflare.com`，确认作为伪装目标的站点可用；不配置前置服务时，Domain Fronting IP/Port 留空或保持未启用状态，相关 PROXY 开关关闭。需要显式公告公网地址时，填自己的真实地址。
3.  本例 Route Through Xray 先关闭，直接保存入站。再新增关联用户 `phone-telegram`，在 MTProto 凭据中生成完整 Secret，启用并保存；从面板复制该用户的 Telegram 代理链接，核对服务器地址、端口和完整 Secret。
4.  在 Telegram 中导入；若手填，使用 MTProto 类型，不选 HTTP 或 SOCKS。
5.  发起 Telegram 请求，同时检查对应服务的连接和日志。

| 字段或选项 | 如何处理 |
| --- | --- |
| 服务器地址 | Telegram 客户端能够到达的真实服务器地址 |
| 端口 | 示例为 TCP `24455` |
| Secret | 使用完整生成值，不截断，不替换成面板密码 |
| Fake TLS Domain | 与生成的 FakeTLS Secret 对应；它不是自己的节点证书 |
| 广告标签 | 没有实际用途先留空，不填任意字符串 |
| Fronting / PROXY Protocol | 没有相应前置服务时不额外启用 |
| Route Through Xray | 根据是否需要衔接 Xray 出站路由决定；启用后继续核对出站 |

该版本的实现管理独立 MTProto 服务，检查端口归属和日志时应看实际服务，不能只凭 Xray 状态判断。它也不会为电脑上的所有应用自动建立代理。[3x-ui MTProto 实现与运行参数](https://github.com/MHSanaei/3x-ui/blob/v3.10.2/internal/mtproto/manager.go)

修改 Fake TLS Domain 后，核对重新保存的 Secret，并重新导入 Telegram 配置，不只改客户端显示名称。若启用 Route Through Xray，再选择实际可用的出站，并结合该服务与 Xray 两侧日志验证。

## MASQUE 配置

MASQUE 是基于 CONNECT-IP 的隧道方案。只有客户端核心支持对应实现时再创建；表单可保存，不代表所有客户端都能通过二维码导入。

1.  新增 `MASQUE`，协议 masque，监听 `0.0.0.0`、端口 `24456`，分享地址填写实际节点域名。
2.  协议页 Address Pool 先只添加一项不冲突的 IPv4 前缀，例如 `172.20.2.1/24`；MTU 留空使用核心默认，或按当前实现填写有效值。
3.  传输页沿用默认 Path `/.well-known/masque/ip/*/*/`。安全页 TLS 填实际证书链与私钥；首次测试可以只选 ALPN h2，使用 TCP，确定成功后再单独增加 h3/UDP。
4.  保存入站后新增关联用户 `phone-masque`，启用并生成 Password。这里的 HTTP Basic 用户名对应 Email，密码对应该用户 Password。
5.  保存用户后，从支持的 JSON 订阅取得配置，导入支持 MASQUE 的客户端，核对认证、路径、TLS 与 ALPN，然后发起真实请求。

| 服务端字段 | 填写方式 |
| --- | --- |
| 协议与传输 | MASQUE，以及对应的 masque 传输 |
| 端口 | 示例 `24456` |
| 安全 | TLS，配置有效节点证书和私钥 |
| 客户端认证 | 面板中的客户端 Email 与 Password |
| 地址池 | 本例 `172.20.2.1/24`；按需配置 IPv4、IPv6，不复用其他隧道网段 |
| Path | `/.well-known/masque/ip/*/*/`，客户端与服务端对应 |
| MTU | 先使用核心默认值 |
| ALPN | `h3` 对应 HTTP/3 UDP，`h2` 对应 HTTP/2 TCP；两者都用时分别检查 |

保存后，使用支持 MASQUE 的 JSON 订阅导入客户端，检查导出的服务器、端口、路径、TLS 和认证。参考版本没有普通 MASQUE 分享 URI 或 Clash 条目，不要因为二维码处没有节点就反复重建记录。

对 `h3` 测 UDP，对 `h2` 测 TCP，再用对应客户端建立真实隧道。`h2` 可以连通，不能说明同端口的 UDP 已经允许；地址池过小或与现有网络冲突，也需要单独处理。[3x-ui MASQUE 字段与导入方式](https://github.com/MHSanaei/3x-ui/blob/v3.10.2/docs/content/docs/en/config/masque.mdx)

## TUN 本机流量接管配置

TUN 在运行 Xray 的主机上创建虚拟网卡，将进入网卡的流量交给路由和出站。它不会给远程手机生成一个“服务器地址加端口”的节点，也不等同于前面的 Tunnel 端口转发。

下面按 Linux 本机做最小配置，先创建网卡，再只接管一个测试目标：

1.  在具备 TUN 设备及相应网络权限的主机上添加入站，协议选 tun，备注 `TUN-Local`。容器部署需要先提供对应设备和权限。基础页如仍要求填写端口，保留一个合法且未冲突的表单值；不要因此把它当成远程监听端口或放行到公网。
2.  协议页 Name 填未被占用的 `xray0`，MTU 用 `1500`，Gateway 添加不冲突的示意 `172.20.3.1/24`；User Level 用 `0`。
3.  Auto System Routing Table 首次留空，Auto Outbounds Interface 用 auto，保存后先确认网卡成功创建。
4.  核对 Xray 的出站与实际物理出口。准备测试时，再将一个真实测试目标的 IPv4 地址以 `/32` 加入自动路由，例如把示意 `203.0.113.20/32` 替换为实际测试地址，保存后检查该目标路由。
5.  从运行核心的这台主机发起不走环境代理的请求，核对目标路由、接口收发及 Xray 日志。成功后才逐步扩大接管范围。

| 面板字段 | 本例填写与含义 |
| --- | --- |
| Name | `xray0`，本机虚拟网卡名称 |
| Desc | Windows 接口描述，Linux 示例不需要额外设置 |
| Gateway | `172.20.3.1/24`，分配给 TUN 的接口前缀 |
| DNS | 该列表按核心文档主要作用于 Windows；Linux 的系统 DNS 另行核对 |
| Auto System Routing Table | 先空，再填真实测试目标 `/32`；`0.0.0.0/0` 会扩大为全部 IPv4 |
| Auto Outbounds Interface | auto，避免核心的出口流量再次送回 TUN |
| Auto System DNS to Gateway / WFP Block Leak | 按平台与核心能力使用，Linux 示例先不启用 |

在 Linux 查看结果：

```bash
ip link show dev xray0
ip address show dev xray0
ip route show
```

`ip route get` 后跟实际测试地址，可以进一步确认出口接口。TUN 创建成功而路由列表为空时，应用流量不会自动进入它；路由已接管但出站又进入 TUN，则需要解决回环。远程维护的服务器扩大到默认路由前，还要安排管理连接与代理上游的实际出口，避免接管自己的连接。[Xray TUN](https://xtls.github.io/config/inbounds/tun.html)、[面板 TUN 字段](https://github.com/MHSanaei/3x-ui/blob/v3.10.2/frontend/src/pages/inbounds/form/protocols/tun.tsx)

## VMess + mKCP 配置

mKCP 是传输方式。本例用自身具备协议加密的 VMess 演示，客户端核心也必须支持这套传输。

1.  新增 `VMess-mKCP`，协议 vmess，监听 `0.0.0.0`，端口 `24464`。
2.  在传输页选 mKCP，按下面的字段保留基础默认值；安全 none，保存入站。本版 mKCP 不搭配 TLS/REALITY。
3.  新增关联用户 `phone-mkcp`，生成 UUID，VMess Security 用兼容的 auto、Alter ID 为 0，保存后导入支持 mKCP 的客户端。
4.  客户端对应地址、`24464`、UUID、VMess 加密与 mKCP 设置。首次验证不启用额外 FinalMask，先检查 UDP 监听和真实请求。

| 字段 | 基础值 | 说明 |
| --- | --- | --- |
| MTU | `1350` | mKCP 数据包尺寸，单位字节 |
| TTI | `20` | 传输间隔，单位毫秒 |
| Uplink Capacity | `5` | 当前核心的上行预算，单位 MB/s |
| Downlink Capacity | `20` | 当前核心的下行预算，单位 MB/s |
| CWND Multiplier | `1` | 拥塞窗口倍数 |
| Max Sending Window | `2097152` | 发送窗口上限，沿用当前默认 |

面板翻译可能沿用旧的带宽标签，核对单位时同时看当前核心说明，不把 MB/s 当成 Mbit/s。新版不再按老教程填写 mKCP Header/Seed；需要旧混淆时核对 FinalMask 的兼容方式，并同步两端。[mKCP 表单](https://github.com/MHSanaei/3x-ui/blob/v3.10.2/frontend/src/pages/inbounds/form/transport/kcp.tsx)、[传输默认值](https://github.com/MHSanaei/3x-ui/blob/v3.10.2/docs/content/docs/en/config/transports.mdx)

## XDRIVE 共享存储传输配置

XDRIVE 从两端都能访问的存储目录中交换会话数据，不通过节点端口直接接收普通连接。选择它前，先准备可用的存储账号、目录与对应权限。

以 VMess 搭配 XDRIVE 为例：

1.  新增 `VMess-XDRIVE`，协议 vmess。基础表单要求的端口使用未冲突值；验证这种传输时检查存储轮询，不将该值视为普通 TCP 监听端口。
2.  传输选 XDRIVE，再按实际存储选择 Service，并填写 Remote Folder 和下表要求的凭据。
3.  不添加独立的入站 TLS/REALITY 层，存储 API 的 HTTPS 连接按其服务要求处理；分块、轮询、并发等高级值先留空或保留默认，保存入站。
4.  新建关联的 VMess 用户，生成 UUID、使用兼容的协议加密并保存。通过 JSON 订阅导入支持 XDRIVE 的核心，检查 UUID、同一 Service、目录和授权都已带入。
5.  两端都能创建、读取、列出和删除所需会话文件后，再发起代理请求；认证错误先查存储 API 与目录权限，不用 `ss` 中缺少 TCP 监听来判断失败。

| Service | 面板怎么填 | 客户端对应条件 |
| --- | --- | --- |
| Google Drive | Remote Folder 填实际会话目录；依次填 Client ID、Client Secret、Refresh Token | 同一存储与目录，三项授权顺序对应 |
| local | Remote Folder 填实际共享目录，例如 `/var/lib/xdrive` | 两端必须访问同一共享存储，单纯路径同名不足以通信 |
| template | 填 Remote Folder、按模板顺序排列的 Secrets，以及 JSON 模板对象 | 模板须实现存储服务的 auth、put、get、list、delete，双方兼容 |

Front Address/Port 是存储 API 的前置访问设置，没有对应拓扑时先留空，不填成面板管理地址。XDRIVE 不提供普通分享 URI 或 Clash 节点，导入时使用支持的 JSON 订阅。订阅包含存储授权，应按凭据保管；不要将真实授权写进博客示例。[XDRIVE 面板表单](https://github.com/MHSanaei/3x-ui/blob/v3.10.2/frontend/src/lib/xray/forms/transport/XDriveForm.tsx)

## 保存后的四项检查

保存成功只表示面板接受了这次修改。还要确认服务应用了配置、对应入口可用，并且真实请求经过了预期路径。

### 确认服务已应用配置

脚本安装且由 systemd 管理时，可以先查看：

```bash
sudo x-ui status
sudo journalctl -u x-ui --since "10 minutes ago" --no-pager
```

同时查看面板中相应服务或核心的错误日志。某些协议由面板内置服务或独立辅助进程处理，日志位置和端口所属进程要按实际实现判断。Docker 部署使用相应容器的状态和日志入口。

### 检查端口监听、TUN 接口或存储通道

![TCP、UDP、TUN 与 XDRIVE 各自需要检查的入口](https://img.iowill.com/file/系统与运维/3x-ui面板入站与客户端配置详解/body2.png)

端口监听、虚拟网卡和存储会话分别检查，随后验证真实应用请求。

先按入站类型选择检查对象，不给所有协议套用端口监听检查：

| 入站或传输 | 应检查的对象 |
| --- | --- |
| RAW、WS、gRPC、HTTPUpgrade、直连 XHTTP、HTTP/Mixed、Tunnel、MTProto | 预期地址上的 TCP 监听，或该方案另外启用的网络 |
| Shadowsocks / SS2022 | 按 Network 分别检查 TCP、UDP，网页请求成功不代表原生 UDP 成功 |
| Hysteria2、TUIC、WireGuard、AmneziaWG、mKCP | UDP 监听；端口可能属于 Xray、面板内置服务或辅助进程 |
| MASQUE | h2 对应 TCP，h3 对应 UDP，两者分别检查 |
| TUN | 本机虚拟网卡、目标系统路由和实际出站接口 |
| XDRIVE | 两端共享存储、API 授权、目录权限和会话轮询 |

以 RAW/REALITY 的 TCP 和 Hysteria2 的 UDP 端口为例：

```bash
sudo ss -lntp 'sport = :24443'
sudo ss -lnup 'sport = :24448'
```

对于需要端口监听的入站，没有对应 socket 时先解决配置或启动错误。仅监听回环地址的入口要从本机、反代或 SSH 转发访问；端口被其他进程占用时，先处理冲突。TUN 和 XDRIVE 则回到各自章节检查接口或存储状态。

再检查主机规则和云平台安全组。使用哪套规则工具就检查哪套，不为验证一篇教程而关闭整台服务器防火墙，也不为尚未创建的全部示例端口统一放行。

### 验证握手与真实请求

对使用本地 SOCKS 入口的代理客户端，可以在客户端电脑运行下面的请求。将 `10808` 换成实际 SOCKS 端口，并确认这个目标会经过正在排查的节点：

```bash
curl --noproxy "" --proxy socks5h://127.0.0.1:10808 \
  --connect-timeout 5 --max-time 20 -sS \
  -o proxy-probe.html -w "HTTP %{http_code}\n" https://example.com/
```

Windows 使用 `curl.exe`，或者把多行命令合成一行执行；Bash 的反斜杠续行不能直接照搬到 PowerShell。读取 HTTP 状态和保存的内容，区分目标页面、目标站拒绝和中间错误。[curl 代理选项](https://curl.se/docs/manpage.html#--socks5-hostname)

WireGuard、AmneziaWG 和 MASQUE 等隧道客户端按实际接管方式验证路由和请求；MTProto 在 Telegram 中验证；Tunnel 使用目标连接测试；TUN 从运行核心的主机发起请求。HTTP/Mixed 入口和普通代理 App 的本地 SOCKS 入口也要按各自地址、端口和认证方式连接。

### 确认浏览器与应用使用同一节点

代理命令成功后，让浏览器或目标应用使用对应入口，检查完整页面、图片和其他资源。若命令成功而浏览器失败，先看系统代理、PAC、TUN、应用自身代理和 DNS 设置，不急着重新生成服务端密钥。

每次改动端口、UUID、密码、密钥、路径或传输参数后，重新获取配置，并确认客户端确实选中了新节点。订阅更新完成，也要检查是否仍在使用旧的同名记录。

## 常见配置错误对照

| 现象 | 先核对什么 |
| --- | --- |
| 面板正常，节点端口没监听 | 入站是否启用、配置是否应用、服务日志和端口冲突 |
| TLS 节点开启橙云后无法连接 | 公网端口是否受支持、传输能否被代理、回源配置和 TLS 终止位置 |
| 把 `0.0.0.0` 填进客户端 | 换成真实服务器地址或实际解析域名 |
| REALITY 握手失败 | 地址、端口、UUID、公钥、Short ID、SNI、Flow、指纹与核心能力 |
| TLS 验证失败 | 证书链、SAN、有效期、系统时间和实际提供证书的服务 |
| WS/gRPC 导入后失败 | 实际路径或 Service Name、传输名称、TLS 与反代对应关系 |
| SS2022 方法正确但认证失败 | 密钥长度、多用户密码组合和客户端方法支持 |
| Hysteria2/TUIC 超时 | UDP 监听、网络规则、证书、认证和客户端支持 |
| WireGuard 有握手但应用不通 | 客户端路由、DNS、Peer 地址和 Xray 出站 |
| AmneziaWG 改完参数全部失效 | 重新导出客户端，检查混淆字段与客户端版本 |
| MASQUE 没有普通分享链接 | 使用支持该协议的 JSON 订阅与核心 |
| HTTP/Mixed 一直提示认证失败 | 检查入站 Accounts 和 Mixed Auth，不使用另一个客户端 Email/UUID |
| TUN 创建后流量未进入 | 看本机接口、系统路由和出站接口绑定，不测试所谓远程 TUN 端口 |
| XDRIVE 没有节点端口监听 | 检查共享目录、API 授权、轮询和 JSON 订阅参数 |
| 保存成功但仍使用旧参数 | 核对运行配置、当前选中的节点和实际导入字段 |

准备给其他设备使用时，为设备生成独立凭据，并保存这套能复现的服务端与客户端参数。共享截图前，删除 UUID、密码、订阅链接、私钥、Secret 和真实服务器地址；之后升级核心或修改拓扑，也保留更新前的配置备份。

## 参考资料

-   [科技小露的多协议配置视频](https://www.youtube.com/watch?v=GqRfXGpWULA)，参考已公开的简介与章节结构；本文具体字段按以下面板文档与源码核对。
-   [3x-ui v3.10.2 入站与协议](https://github.com/MHSanaei/3x-ui/blob/v3.10.2/docs/content/docs/en/config/inbounds.mdx)、[客户端字段](https://github.com/MHSanaei/3x-ui/blob/v3.10.2/docs/content/docs/en/config/clients.mdx)和[传输配置](https://github.com/MHSanaei/3x-ui/blob/v3.10.2/docs/content/docs/en/config/transports.mdx)
-   [Xray VLESS](https://xtls.github.io/config/inbounds/vless.html)、[REALITY](https://xtls.github.io/config/transports/reality.html)与[TLS](https://xtls.github.io/config/transports/tls.html)
-   [VMess](https://xtls.github.io/config/inbounds/vmess.html)、[Trojan](https://xtls.github.io/config/inbounds/trojan.html)与[Shadowsocks](https://xtls.github.io/config/inbounds/shadowsocks.html)
-   [Hysteria](https://xtls.github.io/config/inbounds/hysteria.html)、[TUIC](https://github.com/MHSanaei/3x-ui/blob/v3.10.2/docs/content/docs/en/config/tuic.mdx)、[WireGuard](https://xtls.github.io/config/inbounds/wireguard.html)与[AmneziaWG](https://github.com/MHSanaei/3x-ui/blob/v3.10.2/docs/content/docs/en/config/amneziawg.mdx)
-   [HTTP](https://xtls.github.io/config/inbounds/http.html)、[SOCKS](https://xtls.github.io/config/inbounds/socks.html)、[Tunnel](https://xtls.github.io/config/inbounds/tunnel.html)与[MASQUE](https://github.com/MHSanaei/3x-ui/blob/v3.10.2/docs/content/docs/en/config/masque.mdx)
-   [面板入站编辑器](https://github.com/MHSanaei/3x-ui/blob/v3.10.2/frontend/src/pages/inbounds/form/InboundFormModal.tsx)、[客户端管理表单](https://github.com/MHSanaei/3x-ui/blob/v3.10.2/frontend/src/pages/clients/ClientFormModal.tsx)与[Xray TUN](https://xtls.github.io/config/inbounds/tun.html)