NodeMach 更新后改用端口转发：3x-ui 从安装到 VLESS 可用的记录

我这台 NodeMach VPS 原来用的是关闭防火墙模式。NodeMach 更新以后，这个模式不让用了，只能在 IP 白名单和端口转发之间重新选。

我一开始选了 IP 白名单，配置好以后也能正常用。奇怪的是，过一两天又连不上了，再去改一次白名单又恢复。后来才发现，不是 VPS 有问题，而是我这边根本没有固定公网 IP。公网 IP 一变，前几天填进去的白名单自然就失效了。

看了 NodeMach 的说明以后才明白：没有固定公网 IP，或者本地网络不能直连服务器时，端口转发反而是最省事的方式。不需要追着自己的公网 IP 改白名单，只要访问 NodeMach 分配的中转地址和端口就可以。

于是我把整套配置重新走了一遍，也顺便把过程记下来。这篇不是 3x-ui 的功能大全，只解决三件事：通过中转地址 SSH 登录、打开 3x-ui 面板，以及让创建好的 VLESS 入站能够在客户端正常连接。

文中的域名、IP、端口和 WebBasePath 都是示例，实际使用时要换成自己后台显示的值。

先弄清楚两种端口#

端口转发最容易把人绕进去的地方，是页面里会同时出现两个端口。

• VPS 内部端口：服务真正监听的端口，例如 3x-ui 面板的 17211、VLESS 入站的 57149。
• NodeMach 外部端口：NodeMach 随机分配给中转地址的端口，例如 35606、41349。浏览器和客户端最终访问的是这个端口。

可以把它理解成两条转发规则：

relay.example.com:35606  ->  VPS:17211  （3x-ui 面板）
relay.example.com:41349  ->  VPS:57149  （VLESS 入站）

17211 和 57149 是服务器里面使用的端口，35606 和 41349 才是外面访问时使用的端口。后面的所有配置其实都围着这两条对应关系在转。

第一步：把 NodeMach 切换到端口转发模式#

进入 NodeMach 后台，打开服务器详情页，点击顶部第三个“零信任”标签，然后选择“端口转发”。切换模式以后，原来的白名单或转发规则可能会失效，所以最好当场把需要的规则重新检查一遍。

我先把常见的四个端口加了进去：SSH 的 22、RDP 的 3389、HTTP 的 80 和 HTTPS 的 443。

这里不用完全照抄。Linux 服务器连接 SSH 需要 22；3389 主要是 Windows 远程桌面才会用；80 和 443 则要看自己有没有 Web 服务或证书验证需求。NodeMach 左边显示的“连接地址”是外部地址，右边“指向”的才是 VPS 内部端口。

复制 SSH 那一项的连接地址和外部端口，然后在本地终端连接。比如 NodeMach 给我的中转主机是 relay.example.com，外部端口是 12336，命令就是：

ssh root@relay.example.com -p 12336

这里一定要用 NodeMach 分配的外部端口，不能因为 SSH 默认是 22，就在命令后面继续写 -p 22。

第二步：安装 3x-ui，并自定义面板端口#

SSH 连接成功以后，我用 3x-ui 官方仓库 提供的一键安装命令：

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

这种命令会直接下载并执行远程脚本，地址不要从不明教程里复制，最好回到官方仓库确认后再运行。

安装时我做了三个选择：

1. 数据库使用默认的 SQLite；
2. 选择自定义面板端口；
3. 把面板端口设置为 17211。

SQLite 对我这种单机使用已经足够。17211 也不是必须使用的固定值，换成其他未占用的高位端口同样可以，关键是后面 NodeMach 的转发规则必须指向同一个端口。

第三步：SSL 这一步不要只看“安装完成”#

接下来安装器会询问证书方式。我当时选择的是第二项：Let's Encrypt for IP Address (6-day validity, auto-renews)，也就是给服务器公网 IP 申请有效期约 6 天、自动续期的短期证书。后面的 IPv4、IPv6 等问题，我基本使用默认值继续。

不过这张图里有一个不能忽略的问题：我的证书实际上没有签发成功。终端已经显示 Timeout during connect，并提示确认外部 80 端口能够转发到验证端口。后面虽然仍然出现了 Panel Installation Complete，那只代表面板装好了，不代表 HTTPS 证书也成功了。

3x-ui 的证书说明也写得很清楚：HTTP 验证需要公网 80 端口能够访问服务器。NodeMach 即使把某个随机外部端口转发到 VPS 的 80，也不一定等于公网 IP 的 80 已经打通，所以在端口转发模式下很容易卡在这里。

如果屏幕上明确显示证书签发成功，可以继续使用 HTTPS。如果和我图里一样失败了，就不要看到示例 Access URL 后自己强行加上 https://。可以先按面板当前实际协议访问，再单独处理证书；长期把面板暴露在公网时，更合适的做法是使用自己的域名配合 DNS 验证、反向代理或 SSH 隧道。

另外，即使裸 IP 证书申请成功，最后访问的却是 NodeMach 中转域名，浏览器仍可能因为证书名称和访问域名不一致而报警。这是端口通了和证书匹配完全不同的两件事。

安装结束以后，终端会给出 Username、Password、Port、WebBasePath 和 Access URL。这些信息要保存好，尤其不要公开密码、WebBasePath 和 API Token。

第四步：给 3x-ui 面板增加一条转发#

安装器显示的地址通常类似这样：

WebBasePath: N1rk2ct8ArryUuuil
Access URL: https://203.0.113.10:17211/N1rk2ct8ArryUuuil

但在 NodeMach 的端口转发模式下，直接访问 服务器 IP:17211 会被拒绝。现在回到 NodeMach 后台，新建一条规则，让它指向 VPS 内部的 17211 端口。

假设 NodeMach 给出的连接地址是 relay.example.com:35606，把它和刚才的 WebBasePath 拼起来，面板地址就是：

http://relay.example.com:35606/N1rk2ct8ArryUuuil

如果证书已经正确配置并且与访问域名匹配，再把协议写成 https://。这里替换的是主机和端口，末尾的 WebBasePath 不能丢。

第五步：创建 VLESS 入站#

打开 3x-ui 面板，进入入站列表，点击“添加入站”。我这次选的是 VLESS，地址留空让它监听所有 IP，端口使用 57149，其他传输和安全设置按自己的客户端需求选择。我的截图里使用的是 TCP。

保存以后，入站列表里会看到 57149。这个数字仍然只是 VPS 内部监听端口，客户端现在还不能直接拿它连接。

第六步：转发 VLESS 端口，并在 3x-ui 中添加主机#

再次回到 NodeMach 后台，新建一条端口转发规则，目标端口填写刚才的 57149。保存以后，NodeMach 会再给出一个新的中转连接地址。

假设这次得到的是：

relay.example.com:41349

回到 3x-ui，打开左侧的“主机”页面，点击“添加主机”。入站选择刚刚创建的 VLESS，端点填写 NodeMach 给出的完整中转地址 relay.example.com:41349，然后保存。

这一步的作用，是告诉 3x-ui：服务虽然在本机监听 57149，但分享给客户端时应当使用外部的 relay.example.com:41349。如果不添加主机，3x-ui 生成的订阅或二维码很可能仍然带着内部 IP 或内部端口，导入客户端以后自然连不上。

最后检查客户端里的端口#

添加客户端以后打开二维码或连接信息，重点检查主机名和端口。

正确结果应该是 NodeMach 分配的外部中转端口，也就是上面示例中的 41349，而不是 VPS 内部监听的 57149。确认无误后再导入客户端测试网络。

如果还是连不上，我会按这个顺序检查：

1. NodeMach 的规则是否确实指向 3x-ui 入站端口；
2. 3x-ui 入站是否已经启用，协议和传输方式是否与客户端一致；
3. “主机”里的端点是否填写了 NodeMach 的外部地址和外部端口；
4. 客户端最终生成的地址是否仍然误用了内部端口；
5. 切换安全模式以后，原来的转发规则是否已经失效。

这次真正绕人的只有端口对应关系#

整个过程做完以后，其实并不复杂。NodeMach 负责把外部中转端口送到 VPS 内部端口，3x-ui 负责监听内部端口并生成客户端配置。面板需要一条转发，VLESS 入站还要再建一条，两条不能混用。

我之前用白名单时，总得担心本地公网 IP 什么时候又变。换成端口转发以后，不用再查自己的 IP，也不用过几天重新改一次白名单。只要记住“服务器里看内部端口，浏览器和客户端用外部端口”，剩下的配置就顺了。

这次还顺便踩出了另一个坑：面板安装完成，不等于证书已经签发成功。终端里的红色错误最好当场看完，不然端口明明已经转发，最后却会卡在一个看起来像网络问题、实际是协议或证书不匹配的问题上。