小鸡端口坠机 更改端口教学

3X-UI 换端口教程：检查、放行、修改、更新订阅，附排错与回退

只改 3X-UI 里的端口，不一定就能用；防火墙和客户端配置也要对应。

下面以 Ubuntu + UFW、原生安装的 3X-UI、VLESS + TCP + TLS 普通直出入站为例，将节点业务端口 2053 → 1101。这里的 2053 是示例业务端口；如果它是你的面板管理端口，不要改错。

以下命令均在已登录 VPS 的 root SSH 终端执行，一框一条。普通用户需使用 sudo。 修改前建议保存现有配置或数据库备份，本文省略登录和备份步骤，直接从检查新端口开始。

一、检查新端口是否已经被占用

假设准备使用 TCP 1101：

ss -lntp 'sport = :1101'



    

  

• 只有表头，没有数据行：当前没有 TCP 服务监听 1101，可以继续检查。


• 出现 LISTEN 数据行：已经有服务占用，先弄清楚是什么，不要直接抢这个端口。

这一步只检查监听情况，不证明该端口一定能从外网访问。NAT VPS 还必须使用服务商分配给你的端口范围。

二、放行新端口，暂时保留旧端口

1. 检查 VPS 内的 UFW

ufw status verbose



    

  

如果 UFW 是 active，且默认拒绝入站，就需要对应的允许规则。

本文的 TCP 入站放行方式：

ufw allow 1101/tcp



    

  

查看规则：

ufw status numbered



    

  

应该能看到类似：

1101/tcp    ALLOW IN    Anywhere



    

  

如果显示 inactive，只能说明 UFW 当前没有启用，并不代表其他防火墙也不存在。不要为了换端口就直接启用 UFW；启用前需要先规划并放行 SSH 等管理入口。

不要关闭整个防火墙，也不要为了一个节点放行全部端口。新端口没验证好之前，先保留旧端口的规则。

2. 检查服务商的云防火墙／安全组

如果服务商控制台启用了另一层防火墙，还要允许：

• 方向：入站。


• 协议：TCP。


• 端口：1101。


• 来源范围：按原节点的访问需求配置。

没有启用这一层就跳过；不要把“UFW 已放行”当成所有防火墙都已经放行。

本例是 TCP 入口。客户端显示支持 UDP，不等于一定要给这个入口另开同号 UDP；使用原生 UDP 入站的其他协议，应按实际承载方式配置。

三、在 3X-UI 修改入站并保存

浏览器打开面板，依次操作：

1. 进入 入站。


2. 找到准备修改的那个业务入站，核对备注、协议和旧端口。


3. 点击 编辑。


4. 将端口从 2053 改成 1101。


5. 点击 保存／保存更新，确认没有报错。

本次只改端口。账号、UUID、Flow、TLS／REALITY、证书路径等沿用已有设置。

正常通过面板修改时，3X-UI 会负责生成并应用 Xray 配置，不需要另外手改运行 JSON 或数据库。应用方式可能是热更新或重启，具体取决于版本及变更内容。

如果你自己写过以 inboundTag 匹配的路由，还要核对保存后入站标签及规则引用是否仍对应，不能假定所有自定义引用都会自动跟着变化。

四、确认 Xray 真的监听了新端口

回到 VPS 的 SSH 终端：

ss -lntp 'sport = :1101'



    

  

这次应该出现 LISTEN，对应 Xray 进程。

还要看监听地址：如果只监听 127.0.0.1，就不是给公网直接连接的入口。普通公网入站应使用符合自己部署方式的监听地址，例如服务器的公网 IP 或通配地址。

保存成功不等于已经监听成功。

如果没有新端口：

1. 核对有没有编辑错入站，以及是否真的保存成功。


2. 查看面板的 Xray 状态和错误提示。


3. 检查端口冲突或配置错误。


4. 必要时在面板重启 Xray，再检查监听。

重启 Xray 可能短暂中断现有连接。不要在没有确认原因时反复重启、重装或关闭证书校验。

五、更新客户端订阅，再测试

在 Clash 等客户端里：

1. 更新对应订阅。


2. 查看节点详情，确认端口已经变成 1101。


3. 选择这个节点，重新测试延迟。


4. 实际打开网页，并检查出口 IP 是否符合预期。

如果是手动导入的单节点，旧节点不会自己改变，需要手动改端口，或重新导入面板生成的新分享链接。

多台设备都在使用这个节点时，每台都需要取得新配置。不要拿仍然显示旧端口的客户端，判断新端口是否可用。

节点测速通过也不等于所有业务都验收完成；日常需要的网页、下载或 UDP 应用，分别按实际用途检查。

六、改完还是 Timeout，按这个顺序定位

探针在线、面板能打开、服务器能 ping 通，都不能单独证明某个代理入口正常。反过来，某个入口超时也不能直接证明整台机器或整个 IP 都被封了。

七、新端口失败，怎样改回

如果这次只是修改端口失败，先做最小回退：

1. 在 3X-UI 把同一个入站端口改回 2053，保存。


2. 在 VPS 检查旧端口是否重新监听：

ss -lntp 'sport = :2053'



    

  

3. 核对 2053 的防火墙规则仍然存在。


4. 客户端重新更新订阅，确认端口回到 2053。


5. 重新测试。

前面一直保留旧端口规则，就是为了方便在新端口不通时改回。

如果已经放弃 1101，且确认没有其他服务使用它，可以删除本次新加的通用 TCP 允许规则：

ufw delete allow 1101/tcp



    

  

八、确认新端口正常后，再清理旧规则

确认新入口正常、各客户端已经切换，而且旧端口不再被面板、SSH 或其他服务使用后，再考虑删除旧规则。

先确认旧端口没有服务监听：

ss -lntp 'sport = :2053'



    

  

如果旧规则是本文这种通用 TCP 允许规则，可以删除：

ufw delete allow 2053/tcp



    

  

如有确认提示，核对后再确认。最后检查：

ufw status numbered

九、几个容易混淆的问题

1. 端口可以随便选吗？

没有必须使用的“代理专用端口”。新端口需要没有冲突、服务商允许、防火墙放行，并且实际网络能访问。1101 可以作为候选，但数值合法不代表一定可用；大端口也不天然更快或更安全。

2. 只换端口，要重新申请证书、生成 UUID 吗？

通常不用。保持同一个服务器地址和同一套节点方案时，换端口一般不要求重生成认证材料。TLS 证书校验的是证书中的身份与有效性，不是“给某一个端口单独签证书”。

3. 改落地机的入口端口，也完全照这个流程吗？

还差一步：中转机连接落地的出站端口，也要改为新端口。 落地入站、中转出站、落地防火墙三处要对应。若存在来源 IP 限制，继续保留正确限制，不要为了排错直接改成对所有来源开放。

4. Docker、NAT、CDN 或端口转发怎么办？

这些部署还有额外映射或代理层：容器内外端口、NAT 分配端口、转发目标、CDN 支持的入口与回源设置等都需要对应。本文的原生 TCP 直出示例不能直接覆盖它们。

5. 换端口后就一定不会再出现问题吗？

不能保证。换端口只是改变入口，不会自动解决证书、账号、线路、路由或其他配置问题。是否恢复要看实际测试，不能只看面板显示正常。