admin
a9d2adaf72
把「在已跑 nginx 的 VPS 上从零搭起橙云 + 灰云双链路、并用 3x-ui 管多用户」 的全过程沉淀成技能：五阶段工作流、五条硬性前提、三条易踩反的判据、19 条避坑。 - references/01 前置取证与选型：泛解析不等通、端口取证、nginx 约束下的选型 - references/02 服务端落地：3x-ui 与 sing-box 两条路线，含包名与 2096 冲突 - references/03 nginx 与证书：80 → 签证书 → 443 的顺序、AEAD 套件、口令文件位置 - references/04 面板与多用户：3x-ui 三层模型、加人步骤、CSRF 登录法 - references/05 避坑清单：19 条，正向写做法、括号里附踩过的坑 - scripts/verify-links.sh 与 scripts/3xui-api.py：两个脚本均对真实环境跑通 正文已脱敏，域名/端口/口令/UUID/主机 全部改为占位符。
4.4 KiB
4.4 KiB
name, description, agent_created
| name | description | agent_created |
|---|---|---|
| dual-link-proxy | Deploy and operate a self-hosted proxy on a VPS that already runs nginx, giving one Cloudflare-fronted link plus one direct-DNS link so clients can switch when a path degrades. Covers nginx-side TLS termination, WebSocket reverse proxying to a loopback backend, Let's Encrypt issuance, 3x-ui panel based multi-user management, and the verification criteria for every hop. Use when building or maintaining nginx-fronted VLESS/WebSocket proxy links, adding or revoking users, checking link health, or diagnosing 101/200/401/403/404/520/526 symptoms. | true |
双链路代理：搭建与运维
用途
在一台已经跑着 nginx（通常是宝塔 / aaPanel）的 VPS 上，落地一套「两条链路 + 面板管多用户」的代理：
- 链路一挂在 Cloudflare 后面（橙云），抗干扰、隐藏源站。
- 链路二用灰云 A 记录直连源站，路径短、握手快。
- 两条互为备份，任一条被干扰就切另一条，客户端参数结构一致。
- 后端只监听 127.0.0.1，公网只暴露 nginx 的 443。
- 用户通过 3x-ui 面板增删，每人独立 UUID、独立流量统计、可设到期。
何时使用
- 在已有 nginx 的机器上加代理，且用户明确「域名都走 nginx 转发」。
- 用户要求「每人一个独立账号」并要网页管理。
- 链路出现 101 不通、证书签不下来、面板打不开等故障需要定位。
硬性前提：先确认这四条，再动手
- 确认域名是否真的回源到目标服务器，解析结果不算数，要看 HTTP 响应特征（见
references/01-前置取证与选型.md）。 - 确认目标端口空闲，且不与 nginx 的 80/443 冲突。
- 确认后端选型与「域名走 nginx」这一约束不冲突，Reality 与 nginx 转发互斥。
- 确认改动范围只新增文件，现有站点的 vhost 一行不动。
工作流
阶段一 取证与选型
读 references/01-前置取证与选型.md。产出：链路数量与域名分配、后端选型、端口清单。
关键判据：云解析的泛记录常常存在但不通，必须用 HTTP 状态码区分「CF 自有 404」与「回源 520 / 200」。
阶段二 服务端落地
读 references/02-服务端落地.md。产出：后端在 127.0.0.1 的指定端口跑起来，入站就绪。
这一篇含 3x-ui 与纯 sing-box 两条路线，写明包名、版本、端口冲突处理。
阶段三 nginx 与证书
读 references/03-nginx与证书.md。产出：vhost 建好、证书签发成功、443 可用。
顺序不可颠倒：先建 80 的 vhost 并在其上完成 ACME 验证，再签证书，最后加 443。反过来必然失败。
阶段四 面板与多用户
读 references/04-面板与多用户.md。产出：面板可登录、入站建好、每个用户在两套入站里各有一个客户端。
面板的脚本化登录有前置条件，先读该文档再写自动化。
阶段五 验收
跑 scripts/verify-links.sh 或等效命令。四条判据缺一不可：
- 每条链路的 WebSocket 路径返回
HTTP/1.1 101。 - 每个既有站点返回
200。 - 面板带口令、带浏览器 UA 返回
200。 - 后端服务
active，被替换的旧服务inactive且disabled。
三条容易踩反的判据
- 验证带 basic auth 的站点要带浏览器 User-Agent。aaPanel 及同类面板对非浏览器 UA 一律返回 404，用 curl 默认 UA 判断「服务挂了」会得到假阳性。
- 验证 WS 转发看
101 Switching Protocols，不看200。经 CDN 时先有200 Connection Established（CONNECT 隧道）再是101。 - 判断服务状态要把
systemctl is-active与ss -tlnp的持有进程一起看。孤儿 worker 会继续持有监听端口，此时 systemd 显示 failed 而站点仍然可访问。
资源索引
references/01-前置取证与选型.md—— DNS / 端口 / 选型的取证命令与判据。references/02-服务端落地.md—— 3x-ui 与 sing-box 两条安装路线。references/03-nginx与证书.md—— vhost 模板、acme.sh 流程、TLS 套件收紧。references/04-面板与多用户.md—— 3x-ui 层级模型、加人步骤、脚本登录的 CSRF 处理。references/05-避坑清单.md—— 实际踩过的坑与对应正向做法。scripts/verify-links.sh—— 一次验证链路、站点、面板。scripts/3xui-api.py—— 3x-ui 登录与建入站的命令行封装。