Skip to content

节点端常见疑难问题

对接安装失败

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

安装下载失败 / Connection reset

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

安装过程出现 APT 错误

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

对接成功但是服务器不上线

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

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

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

所有 IP 都被反向墙了的机器就别用了，反正都上不了网。

“断流”

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

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

跳延迟

可能的原因

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

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

miaoko 的 "HTTPS 延迟" 纯属娱乐，请勿当真。因为其中不仅包含了协议的握手延迟，还包含了 DNS 的延迟。只有在客户第一次连接才是这个延迟，后续连接延迟则是接近 ( 所谓的 TLS RTT + 客户到入口的 RTT )。

同步失败 (TCP 端口占用)

寻找占用程序: netstat -tapn | grep :某个端口

中断本地端口上的连接: ss -K sport 某个端口

nodeclient 不会重复尝试监听端口，若您已释放端口，还需要手动重启规则，规则才会生效。

可能的原因

  1. 入口机器上有其他程序监听了这个端口（永久性占用）
  2. 入口机器上有出站连接占用了这个端口（一般是临时性的）

针对第二种原因，双 IP 的机器可设置环境变量 BIND_INBOUND 指定入口监听 IP，这样隧道入口的「入站」和「出站」端口将位于不同的 IP，不会冲突。

奇怪的问题 1

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

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

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

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

奇怪的问题 2

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

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

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

奇怪的问题 3

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

原因：克隆系统造成的。

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

日志显示 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，则大概率是虚拟化超开的问题。与程序无关。

垃圾用户

大部分情况下进程本身并不会占用太多内存, 但是每个 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)，系统内存理应不再大幅增长，再过数分钟就会回落到正常水平。

限速相关的疑问

Q: 限速在哪里？

A: 用户限制相关的功能均在入口。

Q: 不同入口的限速怎么处理？

A: 各个入口独立计算。举例：用户 A （限速 100Mbps）在入口 A 和 B 下各有 1 条规则，那么这两条规则分别享有 100Mbps 的限速。

Q: 规则级限速怎么处理？

A: 规则级限速与用户级限速叠加。举例：用户 A （限速 100Mbps）在入口 A 下有 10 条规则，无论各自限速是多少，这 10 条规则共享 100Mbps 的限速。

Q: IP 数限制怎么处理？

A: 参考上方逻辑。各个入口独立计算，规则级限制与用户级限制叠加。（这是 nc20250326 及以上版本的行为，之前的版本 IP 数限制不准确）

Q: 连接数限制怎么处理？

A: 参考上方逻辑。各个入口独立计算，规则级限制与用户级限制叠加。（版本要求同上）

Q: UDP 能限制速度/IP/连接数吗？

A: 不能。不推荐使用本软件转发 UDP。