主要内容

在复杂网络环境中，如何快速、稳定且可控地搭建一套高可用代理服务，是很多工程师绕不开的命题。本文基于 3x-ui + Docker Compose，从底层架构到实战部署，深入解析代理服务的设计与实现，并结合 VLESS + Reality 等现代协议，构建一套兼顾性能、安全与隐蔽性的解决方案。同时，围绕常见问题（端口、防火墙、Docker 环境等）提供系统化排障思路，帮助你实现真正“开箱即用”的工程化落地。

一、为什么选择 3x-ui？

在代理技术演进中，我们从早期的 Shadowsocks、V2Ray，到如今基于 Xray Core 的增强方案，逐渐走向：

更强的协议灵活性
更高的隐蔽性（如 Reality）
更完善的流量控制与统计

3x-ui 本质是什么？

一个基于 Xray Core 的 Web 管理面板，支持多协议统一管理 + 可视化配置。

核心优势

一站式管理：支持 VLESS / VMess / Trojan 等
Reality 支持：无需证书即可实现 TLS 混淆
流量统计 + 用户管理
Fail2ban 防爆破
Web UI 直观操作

对比常见方案

方案	优点	缺点
Shadowsocks	轻量简单	易被识别
V2Ray	灵活强大	配置复杂
Xray	性能更强	学习成本高
3x-ui	UI友好 + Xray能力	面板需额外安全加固

结论：3x-ui 是工程化落地最优解之一

二、Docker Compose 部署（推荐）

工程上我始终坚持一个原则：

“环境必须可复现”

Docker Compose 正是实现这一点的最佳实践。

docker-compose.yml

services:
  3xui:
    image: ghcr.io/mhsanaei/3x-ui:latest
    container_name: 3xui_app
    volumes:
      - $PWD/db/:/etc/x-ui/
      - $PWD/cert/:/root/cert/
    environment:
      XRAY_VMESS_AEAD_FORCED: "false"
      XUI_ENABLE_FAIL2BAN: "true"
    tty: true
    network_mode: host
    restart: unless-stopped

启动服务

docker compose up -d

三、端口与防火墙（高频踩坑点）

必须开放：

2053 → 管理后台
443 → 实际代理流量

云服务器防火墙

阿里云 / 腾讯云 / AWS：安全组开放 TCP 2053 / 443

本机防火墙检查

使用 `ufw`

ufw allow 2053
ufw allow 443
ufw reload

使用 `firewalld`

firewall-cmd --add-port=2053/tcp --permanent
firewall-cmd --add-port=443/tcp --permanent
firewall-cmd --reload

端口连通性排查

方法1：telnet

telnet your_ip 443

方法2：ss 查看监听

ss -tulnp | grep 443

方法3：systemctl 检查服务

systemctl status docker

四、非 Docker 部署（备用方案）

如果你坚持裸机部署：

bash <(curl -Ls https://raw.githubusercontent.com/mhsanaei/3x-ui/master/install.sh)

但从工程角度，我更推荐容器化（可迁移、可回滚、可扩展）

五、首次登录与安全加固

访问：

http://your_ip:2053

默认账号：

admin / admin

必做三件事

1. 修改管理员密码

这是基本操作，不解释。

2. 修改面板路径（非常关键）

例如：

/admin  →  /sss

访问变为：

http://your_ip:2053/sss

防止被扫描器直接撞库

3. 启用 Fail2ban

环境变量已开启：

XUI_ENABLE_FAIL2BAN: "true"

六、核心：入站策略配置（VLESS + Reality）

这是整个系统的“灵魂”。

核心配置解读

关键字段

"port": 443,
"protocol": "vless",

使用 VLESS，性能更优

Reality 配置

"security": "reality",
"target": "www.microsoft.com:443",

核心思想：

伪装成真实 HTTPS 流量

客户端标识（已脱敏）

"id": "xxxx-xxxx-xxxx"

每个用户唯一 UUID

实际操作步骤（UI）

1. 新增入站

端口：443
协议：VLESS
传输：TCP
安全：Reality

2. 配置 Reality

关键参数：

目标网站（target）：如 www.microsoft.com:443
SNI：同上
公钥 / 私钥：系统自动生成

3. 添加用户

只需关注：

UUID（客户端用）
Flow：建议 xtls-rprx-vision

用户本质只是”认证凭证”

架构本质理解

Client → Reality → Xray → Target Site

核心价值：

流量不可识别
无需证书
抗干扰能力强

七、客户端连接（以 v2rayN 为例）

配置参数

在 v2rayN 中新增节点：

字段	值
地址	你的服务器 IP
端口	443
UUID	上文生成
协议	VLESS
传输	TCP
安全	Reality
公钥	面板复制
SNI	www.microsoft.com

一键导入（推荐）

3x-ui 支持：

分享链接
二维码

工程实践建议：

永远优先用订阅，而不是手动配置

八、常见问题排障

1. 无法连接

检查顺序：

端口是否开放
Docker 是否运行
Reality 参数是否一致
UUID 是否正确

2. 连接成功但无法上网

DNS 问题
SNI 配置错误
target 被墙

3. 面板无法访问

docker logs 3xui_app

九、工程思考：为什么这样设计？

这套方案的核心思想是：

“用真实流量掩护代理流量”

Reality 的本质：

不依赖证书
利用 TLS 指纹混淆
动态握手验证

这其实是：

网络层混淆
协议层伪装
应用层认证

三层协同设计。

十、进阶：Nginx Stream SNI 分流（Web 与代理共存）

问题背景

当 Xray Reality 占用公网 443 端口后，如果还想在同一台服务器上部署 HTTPS 网站（如博客、面板、反向代理），就会遇到端口冲突问题。

直接修改 Reality 端口会破坏其 TLS 特征（真实 HTTPS 流量不会跑在非标准端口上），降低隐蔽性。

解决方案：四层 SNI 分流

利用 Nginx Stream 模块的 ssl_preread 能力，在 TLS 握手阶段读取 SNI 域名，实现流量分发：

公网 443
   ↓
Nginx stream（四层代理）
   ├─ Reality 域名 → Xray Reality（127.0.0.1:10443）
   └─ 其他 HTTPS  → Nginx Web（127.0.0.1:8443）

核心价值：

Reality 流量特征不变，伪装性保留
公网仅暴露标准 443 端口
Web 服务与代理服务长期稳定共存
后续扩展（面板、网站、反代）更方便

实施步骤

1. 修改 Xray Reality 监听地址

停止容器：

cd /home/ubuntu/3x-ui && sudo docker compose down

修改数据库（Reality 改为本地监听）：

sudo sqlite3 /home/ubuntu/3x-ui/db/x-ui.db \
  "UPDATE inbounds SET listen='127.0.0.1', port=10443 WHERE id=1;"

重启容器：

sudo docker compose up -d

验证：

sudo netstat -tlnp | grep 10443

2. 安装 Nginx Stream 模块

sudo apt-get install -y libnginx-mod-stream

3. 配置 SNI 分流

创建配置文件 /etc/nginx/stream.d/sni-proxy.conf：

# SNI 域名路由
map $ssl_preread_server_name $backend_name {
    www.microsoft.com  xray_reality;   # 替换为你的 Reality 域名
    default            nginx_web;
}

upstream xray_reality {
    server 127.0.0.1:10443;
}

upstream nginx_web {
    server 127.0.0.1:8443;
}

server {
    listen 443;
    listen [::]:443;

    ssl_preread on;
    proxy_pass $backend_name;

    proxy_connect_timeout 10s;
    proxy_timeout 300s;
}

在 /etc/nginx/nginx.conf 的 http 块之前添加：

stream {
    include /etc/nginx/stream.d/*.conf;
}

4. 配置 Nginx Web 服务

创建 /etc/nginx/sites-available/web-https：

server {
    listen 127.0.0.1:8443 ssl;
    listen [::1]:8443 ssl;

    server_name _;

    ssl_certificate /etc/nginx/ssl/selfsigned.crt;
    ssl_certificate_key /etc/nginx/ssl/selfsigned.key;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    root /var/www/html;
    index index.html index.htm;

    location / {
        try_files $uri $uri/ =404;
    }
}

启用并测试：

sudo ln -sf /etc/nginx/sites-available/web-https /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

验证

检查端口监听：

sudo netstat -tlnp | grep -E ':(443|8443|10443)'

预期输出：

0.0.0:443   → nginx: master    (公网，SNI 分流)
0.0.1:8443 → nginx: master    (Web 服务)
0.0.1:10443 → xray-lin        (Reality 代理)

测试代理：

curl -x socks5://127.0.0.1:10808 -s -o /dev/null -w "%{http_code}" https://www.google.com

测试 Web：

curl -k -s https://你的服务器IP

十一、总结

如果你追求的是：

稳定
隐蔽
可控
易维护

那么：

3x-ui + Docker Compose + Reality = 当前阶段的工程最优解

最新文章

标签

最近发布时间

2026年 04月 23日 - 基于 3x-ui + Docker Compose 的全链路实践