使用srvany-ng创建iperf3服务后台运行后，客户端测试每次都是7秒后报错 iperf3: ...

这个报错的含义基本就是：你的 iperf3 客户端连到的“对端端口”上跑的不是 iperf3（很可能是 iperf2/iperf，或别的程序），所以控制协议对不上，就会在几秒后报 received an unknown control message (ensure other side is iperf3 and not iperf)。(Super User)

下面按“最常见→最容易验证”的顺序排查（Windows + srvany-ng 场景很适用）：

---

1) 先确认你连到的端口上到底是谁在监听

在服务端机器上执行：

bat
netstat -ano | findstr ":5201"
tasklist /FI "PID eq <上面查到的PID>"

• iperf3 默认监听 TCP 5201（除非你自己改了 -p）。(iperf.fr)
• 如果你发现 5201 上对应的进程 不是 iperf3.exe，那客户端当然会报这个错：把占用 5201 的进程停掉，或让 iperf3 换端口并让客户端也用同端口。

常见坑：你以前装过 iperf2（iperf.exe）并跑在 5001，但你客户端或脚本指定了 -p 5001；或者 5201 被别的程序占了，客户端实际上连到它了。

---

2) 先不要用服务，直接前台跑一次验证“软件本身没问题”

在服务端开一个管理员 CMD，直接跑：

bat
C:\path\to\iperf3.exe -s -p 5201

然后客户端跑：

bash
iperf3 -c <server_ip> -p 5201

如果这样能通，说明 iperf3 没问题，问题就在 srvany-ng 的服务启动参数/路径上。

---

3) 核对 srvany-ng 注册表参数：确保启动的是 iperf3 且带了 -s

srvany-ng 的配置是通过注册表 …\Services\<ServiceName>\Parameters 里的这些值：

• Application：要运行的程序路径
• AppDirectory：工作目录
• AppParameters：启动参数（这里必须有 -s）(GitHub)

举例（你按实际路径改）：

• Application = C:\iperf3\iperf3.exe（不要填成 iperf.exe）
• AppDirectory = C:\iperf3
• AppParameters = -s -p 5201

重点：如果 AppParameters 写错（比如没带 -s，或者拼到奇怪的引号里导致参数没生效），服务可能根本没在 server 模式监听；而客户端连到的可能是别的东西，于是就出现“unknown control message”。

---

4) 不要在服务里再用 -D/--daemon

iperf3 有 -D/--daemon（后台守护）选项。(iperf.fr)
但 srvany-ng 本身就是把程序当服务托管：如果你再加 -D，iperf3 可能会“daemonize 后退出父进程”，srvany-ng 会认为目标程序退出（README 也说明了目标程序退出会导致服务停止/需要重启策略）。(GitHub)
建议：服务里只跑前台模式：-s -p 5201。

---

5) 最后再看防火墙/安全设备（但它通常不是这个报错的主因）

确保 Windows 防火墙放行 TCP 5201（以及你实际用的端口）。iperf3 的控制通道走 TCP，同端口需要可达。(iperf.fr)

---

你现在最快的“定点修复”动作

1. 服务端 netstat -ano | findstr :5201，确认监听进程是不是 iperf3.exe
2. 把 srvany-ng 的 Application/AppParameters 改成：iperf3.exe + -s -p 5201（不加 -D）(GitHub)
3. 重启服务，再测

如果你把你现在的：

• 客户端命令（完整一行）
• 服务端 Parameters 下的三个值（Application/AppDirectory/AppParameters）
• netstat 查到的 5201 PID 对应进程名

贴出来，我可以直接指出是哪一项导致你连到了“非 iperf3”的端口上。

既然手工在命令行跑 iperf3 -s 正常，那问题几乎肯定出在：** srvany-ng 作为服务启动时，实际跑起来的不是同一个 iperf3（或参数没生效 / 路径解析跑错程序）**。iperf3 客户端报的 unknown control message 本质就是“连到的对端不是 iperf3”。

下面按“最有效”的顺序直接定位并修掉（不需要你再猜）：

---

1）先用事实确认：服务启动后，5201 端口到底是谁在监听？

在服务端（装服务那台）执行：

bat
netstat -ano | findstr ":5201"
tasklist /FI "PID eq <上面查到的PID>"

你要看到的结果应该是 iperf3.exe 在监听 5201。
如果看到的是 iperf.exe、cmd.exe、或其他进程——那就是根因：客户端连到的根本不是 iperf3。

很常见：机器上同时有 iperf2（iperf.exe），srvany-ng 配置里没写绝对路径，结果从 PATH 里先找到了 iperf.exe。

---

2）把 srvany-ng 的 Parameters 按“标准姿势”改对（最关键）

打开注册表：

HKLM\SYSTEM\CurrentControlSet\Services\<你的服务名>\Parameters

确保是三个字段分开写（不要把参数塞进 Application 里）：

• Application ＝ C:\iperf3\iperf3.exe （一定要绝对路径，且确实是 iperf3.exe）
• AppDirectory ＝ C:\iperf3
• AppParameters ＝ -s -p 5201

然后重启服务：

bat
sc stop <你的服务名>
sc start <你的服务名>

重点：不要依赖 PATH，不要写成 iperf3 或 iperf3.exe -s ... 这种混在一起的形式。srvany-ng 就是靠这三个值拼命令的。

---

3）服务里不要再加 -D/--daemon

在 srvany-ng 场景下，iperf3 不要加 -D（服务本来就是后台托管）。
-D 在某些环境会让父进程退出/行为异常，srvany-ng 可能认为程序结束，导致实际运行状态混乱。

所以服务参数就保持：-s -p 5201。

---

4）快速产生日志：让你一眼看到服务到底启动了什么

如果你想立刻看到 srvany-ng 实际执行了啥，可以把服务改成跑 cmd.exe 包一层，把输出打到文件：

• Application ＝ C:\Windows\System32\cmd.exe
• AppDirectory ＝ C:\iperf3
• AppParameters ＝

bat
/c ""C:\iperf3\iperf3.exe" -s -p 5201 > C:\iperf3\iperf3_service.log 2>&1"

重启服务后，打开 C:\iperf3\iperf3_service.log，如果里面出现 “unknown option / not found / ……” 之类，就能直接对症下药。

---

5）如果 5201 确实是 iperf3.exe 监听但仍报错（少见）

那就通常是端口没连到你以为的那台服务端（NAT/端口转发/负载均衡/安全设备把 5201 转到了别的设备或别的服务）。

验证办法：在客户端换成直连服务端内网 IP（绕开转发），或在服务端抓一下连接来源：

bat
netstat -ano | findstr ":5201"

看有没有 ESTABLISHED 来自你的客户端 IP。

---

最快的“必杀组合”

1. 服务端跑 netstat -ano | findstr :5201 → 看 PID 对应是不是 iperf3.exe
2. 如果不是：把 srvany-ng 的 Application 改成 iperf3.exe 绝对路径，参数放到 AppParameters，别用 -D
3. 重启服务再测

如果你把下面三样贴出来（直接复制文本即可），我能直接告诉你是哪一处写错了：

• netstat -ano | findstr :5201 的输出
• 该 PID 的 tasklist /FI "PID eq ..." 输出
• 你服务注册表里 Application / AppDirectory / AppParameters 的当前值

那就基本可以定性了：srvany-ng 直接拉起 iperf3.exe 时，进程虽然起来了，但 stdout/stderr/工作目录/参数解析里有一项不符合 iperf3 的预期，导致服务端实际没按你想的方式稳定跑成 “iperf3 server”；用第 4 步用 cmd.exe /c ... > log 2>&1 包一层后，工作目录 + 引号 + 输出重定向都被你“钉死”了，所以就正常了。

最实用的做法：就保留第 4 步这种启动方式，把它当成最终方案（生产环境也很常见）。

推荐的最终配置（保持你现在不报错的方式）

• Application：C:\Windows\System32\cmd.exe
• AppDirectory：C:\iperf3（按你实际目录）
• AppParameters：

bat
/c ""C:\iperf3\iperf3.exe" -s -p 5201 > C:\iperf3\iperf3_service.log 2>&1"

并且：

• 不要加 -D/--daemon（服务托管下没必要，反而容易出幺蛾子）
• 如果你想让日志不无限变大，可以改成每天/每次启动一个新文件名（或用简单的 logrotate 脚本）

你现在可以顺手做的两件事（可选但很值）

1. 打开 iperf3_service.log 看看之前到底哪里不对
   有时会看到类似 “unable to open …” 或者参数解析/权限相关的提示，这样你就知道 srvany-ng 直接启动为什么会异常。

2. 给 iperf3 加一个更“服务化”的参数（可选） 例如明确绑定监听地址（如果是多网卡环境）：

bat
/c ""C:\iperf3\iperf3.exe" -s -B 0.0.0.0 -p 5201 > C:\iperf3\iperf3_service.log 2>&1"

如果你把 iperf3_service.log 里前几十行贴出来，我也可以帮你判断：到底是 工作目录、权限、引号/参数解析中的哪一个导致 srvany-ng 直接启动会“看似启动成功但协议不对”。

有的，而且确实有几种比 srvany-ng 更“服务化”、更好排错的选择（尤其适合你这种 iperf3 命令行能跑、服务跑就怪 的场景）。

1) NSSM（最常用、上手最快）

特点：配置简单（含工作目录/环境变量/重启策略/日志重定向），很多人用它把控制台程序“包成服务”。
注意：NSSM 官方也提示过某些 Windows 版本上服务启动失败的问题，需要用较新的 pre-release build（2.24-101 或更新）。(NSSM)

适合你：你现在靠 cmd /c ... > log 2>&1 才稳定，NSSM 也能把 stdout/stderr 很干净地重定向，通常就不会再出现“服务跑起来但行为不对”的情况。

2) WinSW（更“工程化”，适合长期运维）

特点：用一个 XML 配置把程序包装成服务，支持日志、重启、依赖、环境变量等；社区很大（Jenkins 等生态常用类似方案）。(GitHub)
适合你：如果你希望把配置文件纳入运维/发布流程，WinSW 比 NSSM 更像“标准组件”。

3) Servy（更“现代”的新选项）

特点：定位就是“现代替代 NSSM/WinSW”，强调更完整的控制项（工作目录、日志、健康检查、hook、依赖等）。(Servy)
适合你：如果你想要更强的监控/健康检查能力，可以看看。

4) 任务计划程序（Task Scheduler）（稳定但不等同于服务）

特点：设置“开机启动、无论是否登录、失败重启”等很稳；但它不是 Windows Service 语义（服务管理、依赖关系等没那么原生）。
适合你：如果你只是要“开机自动跑 iperf3 server”，并不强依赖“服务”这个形态，它是个很省心的选择。

---

我给你的推荐（按你的问题命中率）

• 优先：NSSM（你当前问题本质是“服务包装层处理控制台程序不稳/不可见”，NSSM 通常一把梭）(NSSM)
• 想更规范：WinSW（XML 配置、可维护性更强）(GitHub)
• 想更现代特性：Servy（健康检查/更丰富控制）(Servy)

如果你告诉我：你的 Windows 版本（Server 2016/2019/2022 还是 Win10/11）+ 你希望“配置尽量少”还是“可运维性更强”，我可以直接给你一份对应工具的最小可用配置（包含你现在这种日志重定向方式，避免再踩坑）。