Skip to content

节点端常见疑难问题

对接安装失败

请看具体的错误，大概率是网络或者系统有问题。

下载失败 / Connection reset

主要是国内机器的网络问题，推荐使用离线部署功能。

安装过程出现 APT 错误

  1. 您的系统不是 Debian 系，则会出现 apt-get not found 的错误，请重做系统。
  2. APT 软件源配置有误，请上网搜索此类教程。国内机器建议使用清华/USTC镜像源。

安装成功但是服务器不上线

请看节点端日志中具体的错误（可能需要往右边翻页）。

如果日志显示 上报失败 dial xxxxx: io timeout 这类错误，则大概率是节点机器网络有问题。解决方法: 挂代理

若日志显示 lookup xxxxx: timeout 这类错误，则大概率是这台机器设置的 DNS 有问题。

特殊情况：所有 IP 都被反向墙了的机器是无法使用的。

系统问题，等几分钟就可以了，不要手动取消安装进程。如果想优化速度，请在安装之前运行以下命令。

systemctl daemon-reload
systemctl mask systemd-networkd-wait-online.service
systemctl daemon-reload

“断流”

使用已知稳定版的情况下，请优先考虑排查网络以及落地机软件的问题。

如果排除上述问题后，怀疑是转发软件的问题，请留存出入双端日志，在群组内发送包括双端版本、日志等信息反馈。

跳延迟

可能的原因

  1. 入口或出口负载太满。
  2. 网络波动、丢包。
  3. 使用了域名作为地址，而不是 IP，有时解析域名会花费很长的时间（超过 500ms）。

如果 [诊断] 显示正常，而实际客户端 HTTP 连接测试的延迟有 1~2 个 RTT 的波动（广港 50ms 以内，沪日 100ms 以内），则是 0RTT 复用没有覆盖的原因，这种波动是正常且无法避免的。

Socks 协议转发后 UDP 不通

是正常现象，请更换被转发协议，不要使用 Socks。

原因说明：

Socks5 协议（UDP Associate）在代理 UDP 流量时，服务器会动态分配一个随机端口用于 UDP 数据代理。这要求客户端能够直接访问该随机端口。

  • 直连场景（正常）： 客户端直连落地服务器时，客户端连接的 IP 就是落地服务器本身，随机分配的 UDP 端口自然可达，因此 Socks UDP 通常可以正常工作。

  • 端口转发场景（UDP 不通）： 当使用端口转发进行中转时，客户端连接的是入口 IP，但 UDP 数据需要转发到落地服务器。由于端口转发只允许规则中指定的端口通过，而 Socks 动态分配的随机端口不在转发规则内，客户端无法访问这些端口，导致 UDP 代理失败。此限制由 Socsk5 协议和端口转发机制本身决定，无法通过配置消除。

同步失败 (TCP 端口占用)

排查方法

查找占用程序：ss -tapn | grep :<端口号>

强制断开占用连接：ss -aK sport <端口号>

注意：nodeclient 不会自动重试监听端口。若您已释放端口，需手动重启规则以使配置生效。

常见原因

  1. 永久性占用：入口机器上有其他程序已监听该端口。
  2. 临时性占用：入口机器的出站连接占用了该端口（通常为临时现象）。

解决方案

针对永久性占用（原因 1）：

  • 使用上述排查方法找到占用进程并终止进程/释放端口。

针对临时性占用（原因 2）：

设置环境变量 BIND_INBOUND 指定入口监听 IP，使隧道入口的「入站」和「出站」端口绑定到不同 IP，避免冲突。

自 nc20250824 版本起，程序会尝试基于 netlink 断开系统中冲突的连接后重新监听（需 root / CAP_NET_ADMIN 权限）。若仍存在端口冲突，则大概率是永久性占用。

探针显示离线 / 规则同步延迟

现象：探针页显示服务器离线，但已有转发规则正常使用。规则的同步变慢或者根本不同步。

原因：网络问题，多见于国内入口。此时服务器与面板的实时通信受阻，进入离线模式。

离线模式：正在运行的规则继续运行，流量信息延缓上报。若在网络恢复前重启，则会丢失运行的规则和流量。

如何恢复：服务器会主动尝试重连，若网络恢复，则自动恢复在线。若网络质量实在太差，建议挂代理。

多实例冲突

现象：规则 / 探针时好时坏、随机出现大面积的端口占用。

原因：同一机器重复运行节点端。

排查方法： 在节点机器上 ps -aux | grep nodeclient 查看是否有相同的命令，如果有，请卸载多余的。

机器 UUID 标识冲突

现象：两台机器在探针中显示为同一台，IP 反复跳。

原因：克隆系统造成的。

排查方法： rm /root/.config/.nodeclient_uuid 然后重启。

日志显示 too many open files

在某些环境例如 LXC 下，安装脚本默认提升 LimitNOFILE 可能不生效，导致程序最大 fd 数被限制在 1024 65535 之类的数值，无法处理特别多的并发连接。想彻底解决请自查环境。

如果是 nc20251104 之前的版本，这个错误会导致端口掉监听，而且没有日志！

日志显示 ./env.sh: No such file or directory

是正常现象，不是错误。这行日志仅说明没有使用 env.sh 设置环境变量。

日志显示 Please wait panel start

是正常现象，少量出现忽略即可。

更新/重启节点/添加服务器/故障转移结束后，负载不均衡

是正常现象。

  • 出口重启的瞬间（如果有用户在连接）会造成大量连接错误，导致入口认定出口故障，进入故障转移状态。需要等一段时间连接数才能重新均衡。
  • 程序不会打断已有的连接，因为这样会造成用户连接断开。程序会以连接数为标准，优先向负载低的服务器分配新连接。
  • 强制立即均衡的唯一办法是重启入口。（这样会导致用户短暂掉线）

节点端消耗大量 CPU 或内存

1

  • 配置就是要用的，不用浪费。
  • 加密隧道、大量连接调度与密集的网络 IO 操作是要吃 CPU 和内存的，而且要吃很多。
  • Nyanpass 的隧道转发效率已经比 "友商" 和 "开源" 好很多了，请知足。

2

  • Golang 程序倾向于吃更多的内存以提升自身的运行效率。请结合多个内存指标分析，不可单看系统整体占用或程序占用。
  • 当系统可用内存不足，程序会自动归还部分内存。只要没有服务自动重启，或者系统卡死，就是正常的。

3

  • 如果节点程序本身 RSS 占用很低，但是系统总体内存很高，则应该是系统 TCP Buffer 占用的，单纯表明当前系统资源与参数无法负载您的特殊用户。这种没有什么简单的解决办法，只能尝试调节 net.ipv4.tcp_rmem net.ipv4.tcp_wmem net.ipv4.tcp_mem 等参数。 (也有可能是部分用户滥用导致的，排查思路请看下方 垃圾用户 段落)
  • CPU 占用过高，如果系统 CPU 占用中 st% 持续大于 0，则大概率是虚拟化超开的问题。与程序无关。

4

  • 典型场景下（例如 CPU:内存 = 1:2），使用 ny 转发，随着负载升高，一般先爆 CPU，再爆内存。能通过增加系统资源解决的，就加系统资源。若实在无法增加，继续看下方说明。
  • 内存爆满，先排查用户有没有问题（请看下方 垃圾用户 段落），如果没有，那就是真的该加配置了。不建议开 swap/zram 充数，因为会显著拖慢速度。
  • CPU 爆满，可采取以下方法优化（不要期望太多，一般只有 10% 以内的提升）：
  1. 常规系统参数优化，根据自己的情况优化，别用脚本自带那个
  2. 升级最新系统例如 Debian 13，新版内核和驱动有少量性能提升
  3. 不要装多个探针。连接数高的情况下，ny以外的某些探针统计大量连接可能会吃很多cpu，ny也会吃一点。详细解释： https://t.me/c/2002494001/258

连接数过多

如果某个源/目标端口的连接数超过了硬限制（约 6w，部分未优化参数的情况可能更低），可能会产生严重的 CPU 竞争。

注意这里的统计范围是单个源/目标端口，而不是整机（探针显示）的连接数。

这种情况日志通常会大量显示 cannot assign requested address too many open files 或者其他类似错误。

解决办法：检查系统参数；想办法分散连接数。

垃圾用户

大部分情况下进程本身并不会占用太多内存, 但是每个 TCP / UDP 连接需要内存

部分 垃圾用户 可能会开多线程下载导致转发机器内存爆炸（存疑，但一定是用户行为异常）, 这种基本上是 TCP 缓冲区导致的内存爆满

判断是否为此问题

可以使用以下命令查看有问题的 TCP 连接（在出现问题的机器上运行）

ss -nt | awk 'NR==1 || ($1 == "ESTAB" && ($2 > 0 || $3 > 0))'

查看 Send-Q 和 Recv-Q 的值，这里以0为判断依据, 实际应用中只有当值特别大时才能说明这个连接有问题 (大概率为1000000以上)

也可以通过查看系统内所有连接吃掉的总内存大小

查看 /proc/net/sockstat 文件, 其中的 mem 字段值是一个整数, 表示已分配的套接字缓冲区的数量, 以页面为单位 (页面的大小通常是系统的页面大小 例如 4KB)

cat /proc/net/sockstat # IPv4
cat /proc/net/sockstat6 # IPv6

如果这个 mem 值特别高就说明系统内存在异常连接!

查找并封禁问题用户的 IP

首先在入口机器运行以下命令，寻找 Send-Q 或者 Recv-Q 特别大的连接（自行查询 IP 归属地，只看用户的 IP，忽略对端的 IP）

ss -nt | awk 'NR==1 || ($1 == "ESTAB" && ($2 > 0 || $3 > 0))'

如果是入口爆内存，那么运行上面的命令大概率就能找到问题用户的 IP 了。

如果是出口爆内存，那么问题用户有可能发送完数据占满 buffer 之后（此时数据正卡在 出口-落地 这一段，导致出口爆内存）就不再持续发送了，而且出口上无法知道某个连接是由哪个用户 IP 产生的，用上面的方法可能找不到问题用户的 IP。

但是这种用户通常具有高 TCP 连接数的特征，可以通过在入口运行以下命令查找高连接数的 IP。

netstat -tpn|grep tcp|awk '{print $5}'|awk -F: '{print $1}'|sort|uniq -c|sort -r +0n

使用 iptables 封禁问题 IP 后 (iptables -I INPUT -s 问题IP -j DROP)，系统内存理应不再大幅增长，再过数分钟就会回落到正常水平。