Skip to content

节点端常见疑难问题

对接安装失败

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

安装过程出现 APT 错误

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

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

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

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

所有 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 等参数。
  • 如果系统 CPU 占用中 st% 持续大于 0，则大概率是虚拟化超开的问题。与程序无关。