🐞 问题答复

Windows 上接入云端报 certificate has expired（浏览器却打得开门户）

不是门户、也不是网络：这台机器的证书库里有一份与被服务链条同名同密钥、却已过期的证书，应用（Python/OpenSSL）只认本机证书库，于是把库里那张放进链里判它过期；浏览器用自己那套根与链构建，所以同一台机器、同一条链，浏览器照常能开

诊断

• 报错原文形如 certificate verify failed: certificate has expired (_ssl.c:1000)。这句话本身就说明 DNS/TCP/握手都通了 —— 是应用拿到证书之后自己拒绝的，不是门户没应答；门户侧同时刻实测证书链完整、有效期到 2026-12-29，且日志里没有来自该实例的任何请求。
• 行号 _ssl.c:1000 是 Python 版本指纹：3.11=1016（盒子）、3.12=1000（Windows 安装包）、3.13=1032（macOS 安装包）—— 据此可确认失败的是 Windows 安装版。
• 机制：Windows 会把见过的中间证书缓存进本机 CA 存储（Let's Encrypt 的中间证书会换代重签，缓存那份到期后正是这个形态）。OpenSSL 会把库里那份过期证书放进链里并判 expired，而且不会回退到服务器送来的那张有效证书（2026-10-16 在构建 VM 上用同一份 openssl 逐条复现）。
• 浏览器（Chrome/Edge）用自己那套根与链构建，不吃本机 CA 缓存，所以表现为「浏览器能上、应用不能」。
• 应用这一层属产品缺陷：net_tls.py 只在本机库为空时才启用随包 CA，也就是把「库非空」当成了「库可用」；**已修** —— 现在只信随包的根证书，不再采信本机证书库（随下一个版本到达用户）。

你要做的

• 下载证书体检工具并**整个解压**后双击运行（默认只读体检，不改任何东西）：https://www.vlsc.net/mrrc_modern/downloads/MRRC-CertDoctor.zip
• 它会用本机证书库对「门户下发的那条链」复现应用的判定，指出是哪一张证书、在哪个库里；确认后运行 MRRC-CertDoctor.cmd -Fix：把能证明是它的过期证书备份后删掉，必要时再问你是否导入当前的两张 Let's Encrypt 根证书。
• 修好后：从托盘退出 MRRC Modern，再启动它，然后 ☰ -> 接入云端 (Cloud Hub) -> 呼号 + 运维给的一次性口令 -> 申请入口/接入。
• 工具修不好时：桌面会留下 MRRC-CertDoctor-<时间>.zip，把它发给我们。注意诊断包上传与软件更新检查走的是同一条 HTTPS 路径，会一起坏 —— 属同一个原因。

相关代码：net_tls.py（不要把自己的信任判定外包给本机证书库）+ tools/windows/MRRC-CertDoctor.ps1（用户侧体检与修复）

接入云端报 CERTIFICATE_VERIFY_FAILED（诊断包也上传不了、软件更新检查失败）

macOS 打包版（v1.25.0 及更早）没有可用的 CA 信任库：应用里所有外发 HTTPS 都无法校验

诊断

• 报错形如 certificate verify failed: unable to get local issuer certificate (_ssl.c:1032)，这不是 portal 或网络的问题——同一台机器上 curl 访问 portal 是 200、证书链完整
• 根因：安装包把构建机的 OpenSSL 一起带走了，它的默认 CA 路径是构建机的 /opt/local/...（MacPorts），用户机上没有这个目录，于是信任库为空；空信任库同样导致诊断包上传失败
• Windows 与源码运行不受影响（Windows 用系统证书库）—— 前提是那套库健全；反过来，库里有过期/陈旧证书时 Windows 也会失败，见上面 2026-10-16 那一条

你要做的

• 升级到 v1.25.1 即不再发生（随包 CA + 显式信任库；构建闸门会故意把信任库打空再要求真握手）
• 还在旧版本上：在配置文件里加一行 SSL_CERT_FILE=/etc/ssl/cert.pem，然后重启 MRRC Modern
• macOS 配置文件位置：~/Library/Application Support/MRRC-Modern/mrrc_modern.env
• 重启后：接入云端、诊断包上传、软件更新检查应同时恢复

相关代码：net_tls.py（信任库）+ packaging/*/build.*（随包 vendor/ca/cacert.pem）

频谱显示不对：一直是一条光滑的假曲线，看不到真实信号

macOS 打包版 v1.25.0（及 v1.18.0 起的同类构建）真频谱从未启动，界面画的是 S 表合成曲线

诊断

• 日志特征：反复 scope_pipe exited (frames=0, connected=False) 与 Spectrum broadcast active: S-meter fallback；真频谱成功时应有 scope_pipe: first frame received — spectrum active
• 硬件、驱动、库都没问题（FT4222 在 USB 总线上、两个 dylib 在包内，手工用正确目录运行立刻出帧）
• 根因：应用配置里的 FTDI 库目录是相对路径 vendor/ftdi/macos，启动器把它锚到了 Contents/MacOS/（那里什么都没有），而数据树在 Contents/Resources/ —— 于是 scope_pipe 报 FTDI libraries not found 并退出

你要做的

• 升级到 v1.25.1 即不再发生（启动器改为经 _internal 解析相对路径，并补了签名包目录结构的回归测试）
• 还在旧版本上：把配置里的 MRRC_FTDI_LIB_DIR 改成绝对路径 /Applications/MRRC-Modern.app/Contents/Resources/vendor/ftdi/macos，然后重启应用
• 重启后刷新页面：频谱应变成真实底噪 + 信号（可在日志确认 first frame received — spectrum active）

相关代码：macos/launcher.py:load_env（相对 FTDI 目录经 runtime_path 解析）

软件启动后电台选择FTX-1保存重启又变成FT-710，网页也看不到频谱

Launcher 的首启探测白名单 `VALID_MODELS` 只含 ft710/ic7300/ic7300mk2，所选 ftx1 因此每次启动都被判为「未配置」，探测到 Yaesu 应答后把型号改写成 ft710 —— 于是续跑成 FT-710 后端（去找 FT4222 频谱芯片，找不到就退成 S 表合成）

诊断

• 型号回退的根因在 launcher 的首启逻辑，不在配置写入：`macos/first_run.py` 里 `VALID_MODELS = frozenset({"ft710", "ic7300", "ic7300mk2"})`，而 `apply_first_run` 用 `model_unset = model not in VALID_MODELS` 判断；`needs_first_run()` 也要求 `model in VALID_MODELS`，所以保存成 `ftx1` 后配置永远被当作「没定下来」，每次冷启动都重跑一次探测。
• 探测必然把它改回 FT-710：`probe_radio_model()` 只区分两种协议——`return "ft710" if probe is probe_ft710 else "ic7300"`，FTX-1 与 FT-710 同属八重洲 ASCII CAT（`ID;` 会应答，见 CHANGELOG v1.16.0「传输层是移植而非新写」），所以一律判成 ft710；随后 `if model_unset: model = RADIO_MODEL_FALLBACK`（`RADIO_MODEL_FALLBACK = "ft710"`）并 `update_env_file(config_path, updates)` 把 ft710 写回 `%LOCALAPPDATA%\MRRC-Modern\mrrc_modern.env`。
• 现场日志正是这条链路的结果：`2026-10-17 22:49:24,029 [INFO] mrrc: Radio model: ft710, serial port: [已隐去] @ 38400 baud`、`Connected to FT-710 (ID=0840) on [已隐去]`，env.json 里 `"model": "ft710", "scope_type": "ft4222"` —— 型号已被改写，而不是保存失败。
• 频谱空白是型号错误的后果，不是第二个故障：FT-710 后端走 FT4222 真实频谱，而机器上没有这个设备，`scope_pipe` 每轮 5 次 `open_failed:attempt_N:error_2` → `spi_init_failed:all_attempts` → `fatal:cannot_open_device` → `scope_pipe exited (frames=0, connected=False)`，约每 5 秒重启一次（日志里 22:54:01→22:54:26 反复出现）；summary 因此判「出现 S 表合成回退 —— 真实频谱未工作」。
• 另外，Yaesu 家族在 `backends/yaesu/backend.py` 是 `scope_type="none"`（AGENTS.md 记载：由现有 S 表合成器覆盖 UI），所以就算型号正确选成 FTX-1，也不会有真实瀑布——这一点是机型能力的边界，不是坏件。
• 同一白名单还挡住 ftdx10 / ftdx101d / ftdx101mp / ft891 / ic705 / ic7610 / ic7760 等全部 7 个非(ft710/ic7300/ic7300mk2)型号；CHANGELOG v1.16.0 只新增了机型与 profile，`first_run.VALID_MODELS` 与 `probe_radio_model()` 的映射从未随之扩展（SDD/14 的 V2.46、V2.72、V2.92 都无同签名记录），所以 1.28.1 仍带此缺陷。
• `2026-10-17 21:58:15,988 [WARNING] mrrc.audio: Configured audio device 'USB Audio' not found` 属另一件事且已自愈：同一份 stdout 里 22:49:35 `Found configured audio input: [1] 麦克风 (USB Audio Device)` 并成功 `RX audio started`，与本问题无关。

你要做的

• 每次开机/关掉程序重新打开后，进 ☰ 菜单的「连接设置…」，把电台型号重新选成 FTX-1 并保存：保存会写盘并让服务以 FTX-1 重启（这次运行内生效，不必再关程序）。这是当前版本的可用绕过，重启一次就得重来一次。
• 不要在选好 FTX-1 后再「关闭程序重新打开」——那一步正是首启探测把型号改回 FT-710 的时机；要切配置请用连接设置里的保存/重启路径。
• 关于频谱：FTX-1 在本产品里只有 S 表合成，没有真实瀑布（Yaesu 家族的 `scope_type="none"`），这与 FT-710 的 FT4222 频谱不是一回事；需要真实瀑布请使用带 FT4222 的机型（FT-710 / FTDX10 / FTDX101 等）。
• FTX-1 同时属实验性机型（v1.16.0 起「仅接收」）：若切到 FTX-1 后按 PTT 无反应属预期 TX 门禁，需要时在 `mrrc_modern.env` 里设 `MRRC_ALLOW_UNVERIFIED_TX=1` 后再保存重启（发射行为未在真机验证，请谨慎）。
• 想让设置永久保留：把配置副本另存一份（`[已隐去]\AppData\Local\MRRC-Modern\mrrc_modern.env`），每次启动后若发现型号又被改成 ft710，用副本里的 `MRRC_RADIO_MODEL=ftx1` 覆盖并在连接设置里保存一次；根治需要新版 launcher，但它自动覆盖这个键，用户侧无法绕过。

相关代码：macos/first_run.py:VALID_MODELS / needs_first_run / apply_first_run / probe_radio_model（应由 backends.known_models() 派生白名单，并让 probe 返回 "ftx1" 而非 "ft710"）

软件启动后电台选择FTX-1保存重启又变成FT-710

启动器首次自检不认 FTX-1：它把 ftx1 当作“机型未设置”，每次启动都重新探测串口、把机型改写成 ft710 存回配置 —— 不是用户选错，也不是电台的问题

诊断

• 现象与包内运行时状态一致：problem.txt「软件启动后电台选择FTX-1保存重启又变成FT-710」；env.json 里 radio.model=ft710，stdout.log 22:49:24 明确写着「Radio model: ft710, serial port: [已隐去] @ 38400 baud」，随后「Connected to FT-710 (ID=0840) on [已隐去]」——服务端根本没见过 ftx1。
• UI 确实提供 FTX-1，POST /api/setup 也接受它：static/index.html:708 `<option value="ftx1">Yaesu FTX-1F（实验性，仅接收）</option>`；server.py:4073 用注册表校验 `if radio_model not in known_models()`，而 backends/__init__.py 的 _BACKENDS 里确有 "ftx1"。也就是说保存这一步是成功的（env 里写进了 MRRC_RADIO_MODEL=ftx1）。
• 改写发生在服务端之前、启动器里：macos/first_run.py 是「Runs in the launcher (macOS menu-bar app, Windows tray app) BEFORE the server starts」，第 36 行 `VALID_MODELS = frozenset({"ft710", "ic7300", "ic7300mk2"})` —— 一份写死且陈旧的机型白名单，v1.16.0 加入的 ftdx10/ftdx101d/ftdx101mp/ftx1 与 ft891、以及 ic705/ic7610/ic7760 全都不在里面。
• 因此 needs_first_run() 对 ftx1 恒为 True：其判据是 `configured = pwd and pwd != DEFAULT_WEB_PASSWORD and model in VALID_MODELS and (MRRC_PORT_CONFIRMED==1 or 端口非默认)`，model="ftx1" 不在白名单 ⇒ 配置被判定为“未完成” ⇒ 每次启动（含 保存+重启）都走 apply_first_run()。
• apply_first_run() 接着把机型覆盖掉：`model_unset = model not in VALID_MODELS` ⇒ True，于是重新探测串口，探测成功后 `env["MRRC_RADIO_MODEL"] = model; updates["MRRC_RADIO_MODEL"] = model`，再 `update_env_file(config_path, updates)` 写盘 —— 服务端重启后读到的就是 ft710。
• 探测本身也无法区分 Yaesu 家族：probe_radio_model() 结尾 `return "ft710" if probe is probe_ft710 else "ic7300"`，对任何用 ASCII `ID;` 应答的八重洲机器一律返回 "ft710"（probe_ft710 只判 `ser.read(64).startswith(b"ID")`），所以 FTX-1 被“认成” FT-710 而不是探测失败。
• 与「8 次启动 / 时间跨度 21:57:45 → 22:49:37」吻合：用户反复「选 FTX-1 → 保存 → 自动重启」，每次重启都被启动器改回 ft710，于是再次进入连接设置看到 FT-710。
• 历史检索（`grep FTX-1|ftx1|radio_model|update_env_file CHANGELOG.md`、SDD/14 相关条目）里没有同签名记录：CHANGELOG v1.16.0 只加了机型与 profile（`MRRC_RADIO_MODEL=ftdx10 | ftdx101d | ftdx101mp | ftx1`），SDD/14 V2.22 只说明启动器模板暴露了 MRRC_RADIO_MODEL（默认 ft710），没有任何一条修过“启动器白名单不含新机型” —— 属新缺陷，不是回归。同一类缺陷在 /api/setup 已经修过（server.py:4073 的注释：「a hardcoded tuple (which is how ic705/ic7610/ic7760 would have been unreachable from the connection dialog)」），启动器这一份被漏掉了。
• 副带现象均为“跑错后端”的次生结果，不必单独追：scope_pipe `open_failed:attempt_N:error_2` → `spi_init_failed:all_attempts` → `fatal:cannot_open_device` 无限重启（FT-710 才有 FT4222 SPI，FTX-1 的 profile 是 scope_type=none，走 S 表合成）；summary 中「频谱：S 表合成回退」同源。音频那条 `Configured audio device 'USB Audio' not found`（21:58:15）在 22:49 已自愈 —— 22:49:35 日志显示 `Found configured audio input: [1] 麦克风 (USB Audio Device)`，不构成本问题。
• 风险提示：在机型被写成 ft710 的情况下用 FT-710 后端操作 FTX-1，不只是标签错 —— 模式/滤波表与 CAT 字符表按机型不同（CHANGELOG v1.16.0），且 ft710 不设未验证机型发射闸（FTX-1 本应 tx_gated），会对一台未验证机型按 FT-710 假设发 PTT。

你要做的

• 先确认是“被改写”而不是“没点到”：连接设置里选 Yaesu FTX-1F → 保存并重启，然后看 `%LOCALAPPDATA%\MRRC-Modern\logs\server.log` 是否仍是 `Radio model: ft710`。若仍是 ft710，即为启动器改写（1.28.1 已确认）。
• 临时绕过启动器：关掉托盘的 MRRC Modern 启动器，直接运行安装目录里的服务端入口（安装菜单中的「MRRC Modern Server」快捷方式），并确保配置文件 `%LOCALAPPDATA%\MRRC-Modern\mrrc_modern.env` 里有一行 `MRRC_RADIO_MODEL=ftx1`（手改时把已有的那行 ft710 改掉，别写成两行）。不带启动器启动时不会再被改回 ft710。
• 同一份 env 里把串口/波特率写死成实际值（本包是 `MRRC_SERIAL_PORT=[已隐去]`、`MRRC_BAUD_RATE=38400`），这样即使某次仍走了自检，也不会因探测顺序变化换口。
• FTX-1 属未真机验证机型：只做接收不用管；确需发射时在 env 里加 `MRRC_ALLOW_UNVERIFIED_TX=1`（默认拒发），首次发射请小功率、确认频段与驻波。
• 在机型稳定为 ftx1 之前不要用当前（ft710 后端）实例发射 —— 模式/滤波表按 FT-710 下发，且不带未验证闸。接收与频谱（S 表合成）不受影响。
• 顺手把 `%LOCALAPPDATA%\MRRC-Modern\launcher.log` 一起附在下次报告里：它能直接看到启动器那次 `Detecting the radio on N serial port(s)` 的探测与写回，便于确认改写来源；升级到修复启动器机型白名单（改为读取 backends.known_models()）的版本后，就可以恢复用启动器、在连接设置里选 FTX-1F 并持久生效。

相关代码：macos/first_run.py:VALID_MODELS / needs_first_run() / apply_first_run() / probe_radio_model()（白名单应改为 backends.known_models()，探测需返回真实机型或保留用户已选机型，不得把 ftx1/ic705/ic7610/ic7760/ftdx10/ftdx101d/ftdx101mp/ft891 判为“未设置”）

软件启动后电台选择FTX-1保存重启又变成FT-710

1.28.1 的启动器首启探测仍用硬编码三机型白名单（ft710/ic7300/ic7300mk2）判定型号，FTX-1（ftx1）被视为「未设置」，于是每次启动都重新探测并回写成 ft710 —— 这是产品缺陷，不是用户操作问题。

诊断

• 启动器把「型号不在硬编码白名单」当成首启未配置：`macos/first_run.py` 的 `VALID_MODELS = frozenset({"ft710","ic7300","ic7300mk2"})`，而 `needs_first_run()` 的 `configured` 条件要求 `model in VALID_MODELS`。FTX-1 的注册键是 `ftx1`（backends/__init__ 注册表、CHANGELOG v1.16.0「MRRC_RADIO_MODEL=ftx1」），永远不满足，于是**每次启动 launcher 都会重跑自动配置**，`MRRC_PORT_CONFIRMED=1`/`MRRC_FIRST_RUN_DONE=1` 都拦不住。
• `apply_first_run()` 里同一份白名单决定了回写值：`model_unset = model not in VALID_MODELS` → 为 True 就重新探测串口；探测函数 `probe_radio_model()` 只会返回 `ft710`/`ic7300`（FTX-1 也答 Yaesu ASCII `ID;`，因此被认成 ft710），探测不到则 `model = RADIO_MODEL_FALLBACK`（`"ft710"`），最后 `updates["MRRC_RADIO_MODEL"] = model` 覆盖写回配置文件 —— 用户「保存的 FTX-1」被启动器改写掉。
• Windows 走的正是这条路：`windows/launcher.py` 第 14 行 `from macos import first_run`，`main()` 里 `env = ensure_first_run()` 调用的就是上面这套逻辑；rc==42 的配置重启虽会 `load_env(config_path())` 重读文件，但用户「关掉再开」的那一刻会重新过 `ensure_first_run()`，于是又变回 ft710。
• 包内证据一致：`env.json` 的 `radio.model=ft710`、`stdout.log`「Radio model: ft710, serial port: [已隐去] @ 38400 baud」、`Connected to FT-710 (ID=0840) on [已隐去]`，而 summary 显示 1 小时内 8 次启动 —— 与「每次启动都重新探测并回写」吻合。
• 同类缺陷在服务端已经修过、启动器这一份被漏掉：`server.py` 的 `/api/setup` 用 `known_models()` 并注明「Registry-derived: …instead of being rejected by a hardcoded tuple (which is how ic705/ic7610/ic7760 would have been unreachable from the connection dialog)」；`macos/first_run.py` 仍留着手写三元组，所以 v1.16.0 之后新增的 ftx1/ftdx10/ftdx101d/ftdx101mp/ft891/ic705/ic7610/ic7760 全部会被回退成 ft710。与 CHANGELOG:1635（V2.33「连接设置保存与首启探测…曾静默覆盖型号默认值」）同属「首启探测覆盖用户选择」这一类，只是那次修的是波特率分支、型号分支从未修。
• 包内其它报错不是本问题：`scope_pipe: open_failed:attempt_N:error_2` + `fatal:cannot_open_device` 表示这台机器上没有可打开的 FT4222 设备（FTX-1/非 FT-710 本来就没有 FT4222 波形源，v1.16.0 明确「没有真机频谱数据源，UI 用 S 表合成，不伪造瀑布」）；`asyncio … ConnectionResetError [WinError 10054]` 是浏览器/客户端断连的噪声；`ft8-worker.log` 的 `BrokenPipeError … EOFError` 是进程退出时 worker 被回收。这三类不解释型号回退。
• 需要注意的一点：日志里电台以 `ID=0840`、FT-710 的 CAT 应答；如果现场实际接的是 FT-710，那么选 FTX-1 本身也不可用（FTX-1 模式码 H/I 与滤波 SH 前缀都不同）。型号回写是缺陷，但「该选哪个型号」要以机身上的机器为准。

你要做的

• 先彻底退出 MRRC Modern（托盘/黑色命令窗口都要关，任务管理器确认没有 MRRC-Modern.exe / MRRC-Modern-Server.exe 残留），否则下一次启动仍会被探测覆盖。
• 用记事本打开 %LOCALAPPDATA%\MRRC-Modern\mrrc_modern.env，把 `MRRC_RADIO_MODEL=` 改成 `ftx1`（若真要把 FTX-1 当发射机，再补一行 `MRRC_ALLOW_UNVERIFIED_TX=1`，否则 PTT/TUNE 会被未验证机型门禁拒绝）；顺手确认 `MRRC_SERIAL_PORT=[已隐去]`。
• **不要用桌面/开始菜单里的「MRRC Modern」图标启动**（那是 launcher，会重新探测并把型号写回 ft710）。改用安装目录下的 `MRRC-Modern-Server.exe`，或开始菜单里的「MRRC Modern Server」快捷方式，再在浏览器打开 https://127.0.0.1:8888。
• 启动后到日志里核对一行：应出现 `Radio model: ftx1`（不是 ft710）；若仍是 ft710，说明 launcher 又跑了一次，按其托盘菜单完全退出后再用上面的 Server 入口启动。
• 如果只想稳定使用：把型号设回实际电台（例如 FT-710 → `ft710`），并在修复版发布前不要再在「连接设置…」里切换到 ft710/ic7300/ic7300mk2 以外的机型。
• 顺便清理环境噪声：这台机器没有可用的 FT4222 设备，FT-710 的真频谱需要 FTDI 驱动/设备（`FT4222.dll`+`ftd2xx.dll` 已加载但 `error_2` 打不开）；若确实是 FT-710 且要真频谱，请插好 USB 波形口并确认驱动，否则瀑布会一直是 S 表合成。

相关代码：macos/first_run.py:needs_first_run()/apply_first_run()（VALID_MODELS 硬编码三键 → 应由 backends.known_models() 派生，探测失败时保留用户已选的型号而不是回写 ft710）

关闭蒲公英VPN还是无法进入电台所在网络，打开bg7zhs.mrrc.vlsc.net网页显示502bad gateway电台所在网络使用了花生壳P5路由器。

本机服务与电台一切正常（启动完整、[已隐去] 已连、频谱/发射正常），502 出现在云端入口→本机隧道的链路；这与本仓记录过的『入口 502 而租户侧一切看起来正常』同签名，1.25.3 应已包含相关修复 → 按回归排查。

诊断

• 本机侧健康：stdout.log 显示 `SSL enabled`、`Connected to FT-710 (ID=0650) on [已隐去]`、scope-init 完成、`Poll scheduler started (7 tasks)`，radio.serial_connected=true —— 应用不是崩溃/未启动状态，因此 502 不是本机服务没跑起来。
• 电台在正常工作：server.log 尾部 `Session metrics: listeners 0 | operators 2 | uplink spectrum 293.0 kbps` 与 `TX session: frames=210 fed=210 written=205 write_err=0 peak=45%` —— 收/发链路在跑，租户侧看起来一切正常，正是历史条目描述的 502 画面。
• 云端隧道是本实例配置的一部分：stdout.log 有 `cloud_hub: cloud hub: clearing a stale frpc (pid 7424) holding this instance's tunnel` —— 说明本实例已接入 MRRC 云（bg7zhs.mrrc.vlsc.net 走 hub→frpc 回连），且 v1.25.2 的残留 frpc 清理在运行。
• 用户报 `打开 bg7zhs.mrrc.vlsc.net 显示 502 Bad Gateway`：与 CHANGELOG v1.24.2『隧道从界面接入时永远不启动 —— 入口一直 502，而租户侧看起来一切都对』、v1.24.7『入口 502 却没人提示重启』、v1.24.8『一台已接入的机器重启之后，入口会一直 502，直到有人点一下设置』、v1.25.0『hub 拿登记证书校验上游，入口会一直 502 而没有任何东西会去重启』完全同签名。
• 版本判据：env.json version=1.25.3（frozen, Windows），而上述 502/隧道生命周期修复在 v1.24.7 / v1.24.8 / v1.25.0，均已包含在当前版本中 ⇒ 不是『版本早于修复』，按回归排查；v1.25.4（V2.73）只补了 macOS 的 frpc 清理那一半，对 Windows 无影响。
• 环境提示（不能仅据此判环境）：problem.txt 里用户提到 蒲公英 VPN 与 花生壳 P5 —— frpc 是出站连接、本不需要同网段/VPN，这两层叠加可能干扰，但历史签名的优先级高于环境推断，故仍需按隧道链路排查。
• 次要异常（与本 502 无直接因果，供参考）：server.log 通篇为 `get_meter(RM8): unparseable response`（RM8 回读全是二进制垃圾），可能只是 RM8 度量解析噪声，也可能是串口被第二个进程占用，需在真机确认只有一个实例持 [已隐去]。

你要做的

• 打开应用「设置 → 接入云端」，查看入口地址与状态：若显示「还需重启应用以启用新证书」(cert_reload_required)，点重启按钮让新证书生效——老证书会过不了 hub 的上游校验，表现为入口一直 502。
• 完全退出 MRRC Modern（含托盘/任务栏，确认没有第二个 server/frpc 进程）后重新启动：应用启动时会把已接入的隧道自动拉起；随后到 `logs/stdout.log` 确认出现 frpc 的 `login to server success` 与 `start proxy success`（只有这两行出现，入口才会通）。
• 确认网络路径：蒲公英 VPN 已关（已做）；frpc 只需本机能出公网，不需要与电台同网段。若 花生壳 P5 开启了『内网穿透/VPN 叠加/DNS 劫持』类功能，先按普通 NAT 放行或关掉其叠加功能，避免与 frpc 的出站长连接冲突，然后重启应用。
• 确认没有重复实例：启动日志里 `Sending scope-init CAT commands...` 只应出现一次、`MRRC-Modern`/`frpc` 进程各只有一个；出现成对日志或两个 frpc 就是重复实例在抢 [已隐去] 和隧道代理名，先全部关掉再单开一个。
• 若以上仍 502：在「接入云端」重新刷新，或撤销后重新申请以重建端口路由（v1.24.3 起同呼号复用原端口，避免路由指向空端口）；并把最新版（≥1.25.4）装上后重试，同时保留 logs/stdout.log（含 frpc 输出）与 hub 侧 frps 日志供回归定位。

相关代码：cloud_hub.py:TunnelProcess（隧道启动/注册）+ server.py:_cloud_start_tunnel（启动时自拉隧道、证书判据）

偶尔重启系统和APP发射有声音大部分还是发射没有语音输出，用CQ键发射能听到CQ CQ CQ…的呼叫，IC7300/29.6FM

服务端收到 0 帧麦克风上行（frames=0/peak=0%，CQ 走服务端注入却正常），与仓库 V2.71 记录并修复过的「键控了却没有声音」同签名，而现场 1.25.5 已包含该修复，按回归排查。

诊断

• 现场版本 1.25.5（env.json.version），而 v1.25.4 的 CHANGELOG「同批到达：这一个包也是 FT-891 和『键控了却没有声音』到达用户的那个包」段明确该修复（SDD V2.71）随安装包发布，源码包内含 `_claim_tx_owner_for_token`/`_same_session_uplink_takeover`（CHANGELOG.md:389-404）⇒ 当前版本应已包含该修复。
• 失败签名与历史逐字吻合：多次 `TX session: frames=0 fed=0 decode_fail=0 written=0 write_err=0 queue_drops=0 peak=0% non_owner_drops=0`；V2.71 现场取证正是「四次发射全是 frames=0 fed=0 written=0 peak=0%，电台键控了、调制为零」（SDD/14-version-history.md 的 V2.71 行）。
• 日志同时出现多条 /WSaudioTX 与 non-owner 丢弃：`Audio TX client connected (2 total, owner=False)`、`TX audio from non-owner client ignored (drops=1) — another client owns the uplink`、其后 `Audio TX client disconnected (1 remain, owner=True)` —— 正是 V2.71 描述的多 socket 上行认领场景。
• CQ 键能听到呼叫（problem.txt）：CQ 由服务端 cq_player/TxSession 直接灌入 TX 队列，证明电台键控、TX 输出设备与电台调制输入通路均正常；因此故障只在上行（浏览器/App → 服务端）。
• 服务端音频设备另有环境噪声但不解释本症状：`TX audio started: [5] 扬声器 (USB Audio CODEC ) ... actual=48000Hz, channels=1` 成功、CQ 也走该设备；而同批 `Configured audio device '麦克风 (USB Audio CODEC)' not found`（配置名末缺一个空格）、`Found configured audio output: [27] ... (WDM-KS)` 后 `TX open failed x3 ([Errno -9999] Unanticipated host error) — re-initializing PortAudio`、`Multiple USB audio outputs: [5]/[13]/[18] — using [5]` 属 USB 重枚举/设备名与设备索引漂移，影响的是设备选择而非帧数。
• summary 的 Traceback 均为 `_ProactorBasePipeTransport._call_connection_lost`（Windows asyncio 断连噪声），与无语音无关；`scope_pipe open_failed/fatal:cannot_open_device` 早于本次发射（12:26），且 13:43:40 已有 `ic7300.scope: CI-V scope: first complete waveform — spectrum active (bins=475)`，频谱非本症状原因。

你要做的

• 只保留一个发射客户端：关闭其它浏览器标签页、另一台设备或另一个 App 的登录（日志显示同时有 2 条 /WSaudioTX 与一条 non-owner 丢弃）—— 上行同一时刻只归一条会话，多余的麦会互相压制。
• 在发射用的那个浏览器里确认麦克风权限与输入设备：站点设置→麦克风=允许，且输入不是 ToDesk Virtual Audio 等无信号虚拟声卡（被拒或选错设备时浏览器会一帧都不发，正是 frames=0）。
• 完全退出浏览器/App 再重开并重新登录一次后发射（清掉页面重载留下的半开旧 socket，避免认领落在不再送音频的旧连接上）。
• 升级到 1.25.5 之后的最新安装包（现行仓库侧为 1.27.x），重装后先只用单个客户端做一次发射验证。
• 排查环境时把音频设备写死为启动设备清单里的 MME 条目（如 MRRC_AUDIO_RX_DEVICE=1、MRRC_AUDIO_TX_DEVICE=5，或核对设备名结尾空格），避免 [27]/[28] WDM-KS 条目反复 -9999 打不开；改完重启服务再试。
• 自检判据：发射时看日志 `TX session` 行，`frames`/`written` 应 >0、`peak` 非 0%、`non_owner_drops`=0；若仍 frames=0，说明发射端浏览器/App 根本没送音频，按上面客户端侧继续排除。

相关代码：server.py:_claim_tx_owner_for_token / _same_session_uplink_takeover / _assign_tx_owner_on_connect（TX 上行认领）；static/ft710_main.js + tx_capture_worklet.js（浏览器麦采集是否出帧）

手机端发射声音太小

与 SDD V2.78（同日 2026-10-10、同为 v1.25.4 + IC-7300 的发射声音问题）同签名：软件链路清白，根因在电台侧调制输入源（Icom MOD Input / USB MOD Level），非产品缺陷。

诊断

• 软件链路是清的：TX 声卡选中正确且命中 USB 声卡 —— `TX audio started: [4] 扬声器 (USB Audio CODEC ) (host=MME, default=44100Hz, actual=48000Hz, channels=1)`；`env.json` 里 `configured_tx="扬声器 (USB Audio CODEC )"`、`radio.model="ic7300"`、`device_rates.tx=48000`。
• 服务端确实把语音写进了电台：`TX session: frames=85 fed=85 decode_fail=0 written=83 write_err=0 queue_drops=0 peak=21%` 与 `frames=121 fed=121 written=112 peak=0%`。`peak` 是服务端解码后 PCM 实测峰值（SDD V2.71 定义，`server.py:2740`），写入无差错、无丢帧。
• 电台也确实在发射且有调制：`TX meters active: RF_PWR=100W | COMP=0 ALC=101 PWR=52 SWR=15` —— `ALC` 非零说明电台当时收到了调制信号（对照 V2.78：ALC=0/PWR≈0 才是「调制没进来」）。
• 因此「声音太小」是**电平**问题而非通路问题：peak=21% 偏低（V2.78 的已知良好现场是 peak=52%），而多次 `peak=0%` / `frames=0 fed=0` 的发射是手机端当次根本没送音频（按键但未采集到声音）。
• 本仓历史同签名：SDD V2.78（2026-10-10，同日同版本 v1.25.4、同为 IC-7300）把两份上报的根因定为**电台侧调制输入源**（Icom `SET → Connectors → MOD Input`：`DATA OFF MOD` 未选 USB 时，FM 是死载波、SSB 表现为「功率很小或没有」），并明确『不是产品缺陷』；产品侧只补了文档，无代码修复可回归。当前日志与该结论一致（本包即 `20261010-220406-5793`，与 V2.78 记的 `20261010-205200-6e3c` 同批）。
• 噪音（非本问题）：233 条 Traceback / 249 条 ERROR 全是 `ConnectionResetError: [WinError 10054] 远程主机强迫关闭了一个现有的连接` —— 手机端 WebSocket 非正常断开，属客户端网络抖动；`scope_pipe: fatal:cannot_open_device` 来自早前的 FT-710 会话（14 次启动时间跨度 10-09→10-10），当前 `radio.scope_type="civ27"` 的 IC-7300 不走 FT4222；`cloud hub: cannot run frpc: [WinError 5]` 与发射音质无关。

你要做的

• 在 IC-7300 面板上核对 `SET → Connectors → MOD Input` 三项（这是本类问题的第一处）：`DATA OFF MOD = USB`（想同时留手咪就选 `MIC, USB`）、`DATA MOD = USB`、`USB MOD Level ≈ 50`（不要为 0）。
• 同组确认 `USB SEND = OFF`（MK2 同组另有 `USB Keying (CW/RTTY)` 也保持 OFF）。
• 说话时看电台 ALC 表是否摆动 —— 不动＝调制没进来，回去改 `MOD Input`（对应 `docs/OPERATION_GUIDE.md` §0.6.2 验证清单第 5 条）。
• 网页端把设备侧麦克风增益 `🎙 Vol` 滑杆往上调（0–200 → 0–2×，100 = 原值；见 CHANGELOG「Device-side mic gain」条），目标让服务端日志 `TX session ... peak=` 稳定在 40% 以上。
• 手机侧：确认浏览器已获麦克风权限、系统媒体音量非静音、不要按住麦克风孔、尽量用耳机麦克风贴近说话；若日志里某次发射是 `frames=0 fed=0`，说明那一下手机没采到音（重新授权/换浏览器重试）。
• 若上述都到位而对方仍觉小，把电台 `USB MOD Level` 从 50 逐步上调（如 70–80）再试，注意别过载（ALC 顶格反而失真）。

相关代码：无代码缺陷；用户指引见 docs/OPERATION_GUIDE.md §0.6.2（IC-7300 MOD Input）与 static/modules 的 🎙 Vol 设备侧麦克风增益

FT-7300开机就发射

日志签名 `TX session: frames=0 … written=0 … peak=0%`（键控了却没有声音）与 v1.25.4 修复的「同一 30 天令牌下多条 /WSaudioTX 上行归属错误」同签名，而当前版本正是 1.25.4（应已含该修复）→ 按回归排查。

诊断

• 日志反复出现 `TX session: frames=0 fed=0 decode_fail=0 written=0 write_err=0 queue_drops=0 peak=0% non_owner_drops=0` —— 键控确实发生，但一帧上行音频都没到服务端，正是 v1.25.4 CHANGELOG 记的「键控了却没有声音」现象。
• 包内可确认**同一会话存在多条 /WSaudioTX**：`20:34:14,608 [WARNING] mrrc: TX audio owner disconnected during TX! Forcing RX` 之后紧跟 `20:34:14,675 TX audio ownership promoted to remaining client (1 total)` 与 `20:34:14,676 Audio TX client disconnected (1 remain, owner=True)` —— 与 v1.25.4 描述的「页面重载留下的半开旧 socket / 同一登录的两个标签页」场景一致。
• 当前版本 = 1.25.4（`diagnostics/env.json` "version": "1.25.4"，`manifest.json` "version": "1.25.4"），而 CHANGELOG v1.25.4 明说该包已含修复：`_claim_tx_owner_for_token`、`_same_session_uplink_takeover` 都在里面（源码包逐字节核对）。因此这不是「版本太旧」，而是修复未生效的回归。
• 服务端 `is_transmitting` 由 CI-V 读回驱动（`radio_state.py` 中 `tx_status` → 派生 `is_transmitting`；`civ_controller.py` 的 `_try("tx_status", self.get_ptt)`），所以电台确实处于发射态；结合 frames=0，用户看到的「开机就发射」就是「电台被一条不再送音频的 socket 键控着、却无声」。
• 次要环境噪声不构成 frames=0 的判据：`[Errno -9999]`、`Configured audio device '麦克风 (USB Audio CODEC)' not found`（实际设备名多一个尾空格）影响的是服务端↔电台的声卡，而不是浏览器上行帧计数；Windows 的 `_ProactorBasePipeTransport._call_connection_lost` 是已知良性噪音。

你要做的

• 先排除多 socket 干扰：把所有打开该网页的标签页/窗口全部关闭（尤其 ToDesk 远端里和本机各开的一个），然后**只开一个**页面重新登录再试发射，同一账号不要同时开两个标签页。
• 检查浏览器麦克风权限与输入设备：该机存在 `麦克风 (ToDesk Virtual Audio)`，请把系统默认输入改为 `麦克风 (USB Audio CODEC )`，并允许浏览器使用麦克风后再按键。
• 若单一标签页下仍无声：按回归上报——打开 🐞 页面生成本次诊断包（含 `diagnostics/client.json`，本次包内该文件内容缺失），在答复里注明「1.25.4 上仍复现 frames=0」并附新的 `#编号`。
• 临时规避：发射前先松开再重新按下 PTT，并观察该次 TX 会话的 frames 是否仍为 0，以确认是否为上行归属问题；确认期间可用功率/SWR 表判断电台是否真在发信。

相关代码：server.py:_claim_tx_owner_for_token / server.py:_same_session_uplink_takeover（TX 上行归属；配套 _register_tx_socket/_forget_tx_socket）

云端申请500

「云端申请500」与 v1.24.0 引入云端接入时那个未导入 cloud_hub 的缺陷完全同签名，当前版本（1.24.0）早于修复版本，升级到 v1.24.1 及以上即可解决。

诊断

• 症状与你上报的完全一致：CHANGELOG v1.24.1 条目标题即「接入云端第一次真按就 500：那个模块谁也没导入」，正文写明「v1.24.0 把接入搬进了设置菜单，但真按『申请』只会得到一个 500」（CHANGELOG.md:707、709）。
• 根因是打包版 server.py 从未 `import cloud_hub`，导致申请端点在运行时报 NameError 并返回 500：现场堆栈 `File "server.py", line 4035, in api_cloud_apply` → `File "server.py", line 3987, in _cloud_portal` → `NameError: name 'cloud_hub' is not defined`（CHANGELOG.md:711-713；SDD/14-version-history.md 的 V2.64 同款记录）。
• 你的包版本恰是出问题的那个：env.json 报 `"version": "1.24.0"`、`"frozen": true`（打包版），而修复在 v1.24.1；也就是说 1.24.0 完全不含该修复，任何一次「申请」都必然 500。
• 当前仓库 HEAD 已含修复：server.py:67 有 `import cloud_hub`，_cloud_portal（server.py:5114）与 api_cloud_apply（server.py:5304）都正常引用 —— 证明这是已修复的旧版回归，不需要新改代码。
• 包内其余迹象（18:59 的 [已隐去] `PermissionError(13, '拒绝访问')`/`FileNotFoundError`、更早的 `Configured audio device 'USB Audio' not found`、频谱一时走 S 表回退）都属于串口被占用/设备名不符的瞬时环境问题，且日志显示 19:22 重启后串口已连上（`Connected to FT-710 (ID=0800) on [已隐去]`）、真频谱已 `first frame received`，与你上报的云端申请 500 不是同一件事。

你要做的

• 将 MRRC Modern 升级到 v1.24.1 或更高版本（v1.24.0 是首次加入云端接入、申请按钮必 500 的版本）：从 www.vlsc.net 下载最新安装包覆盖安装，或在应用内用「检查更新」。
• 升级并重启应用后，再打开「设置 / ☰ → 接入云端」填呼号提交申请，此版本起申请才可能返回正常结果。
• 若升级后申请仍报 500，请立刻用 🐞 生成新的诊断包发回，并附上点击「申请」的确切时间点。
• 本次包内另有两处环境提示可顺手排除：18:59 前后 [已隐去] 曾被其它进程占用（PermissionError/端口不存在），请确认没有第二个程序（如串口调试工具、另一个实例）占着 [已隐去]；音频设备名配置为 'USB Audio' 而实际设备名是 'USB Audio Device'，可在设置里选实际设备后重试。

相关代码：server.py:api_cloud_apply / server.py:_cloud_portal（1.24.0 缺 `import cloud_hub`；修复见 server.py:67 的 import 与 v1.24.1）

发射功率小/没有？ 你看看

同一条根因的 SSB 版本：电台在发射，但实测 `ALC=0`、`Po≈0`，而服务端同时在把音频写进电台 USB 声卡 —— SSB 没有调制就没有射频功率；先查电台 `MOD Input`（`DATA OFF MOD` / `DATA MOD` = `USB`）

诊断

• 「功率没有」在 SSB 下正是「没有调制」：`TX meters active: RF_PWR=56W | COMP=0 ALC=0 PWR=0 SWR=0` —— `RF_PWR=56W` 是功率设置值，`ALC` / `PWR` 才是实测。本段日志三次实测（18:05 / 20:17 / 20:46）全部 ALC=0，即调制器没有输入
• 同时服务端在正常送音频：本段日志里连服务端自带的 CQ 录音也完整播完（`CQ: keyed the radio` → `CQ session: written=307 write_err=0 queue_drops=0 mic_drops=0`，6.1 s 全帧），浏览器麦克风一路也有大幅值（`peak=100%`），所以不是「没送出音频」
• Icom 的调制输入源由 `SET` → `Connectors` → `MOD Input` 决定：`DATA OFF MOD` 管非 DATA 模式（SSB / AM / FM 语音），不含 `USB` 时语音发射只有载波 —— FM 表现为死载波、SSB 表现为没有功率，与同批另一份报告（对方听到发射但没声音）同源
• 另外本次语音峰值起伏很大（`peak=1%/5%` 与 `peak=100%` 交替），手机麦克风的距离/增益也要一起调整；调制打开后 ALC 应稳定有读数但不进红区
• 次要观察：`queue_drops` 多次出现（10~226），这台 Windows 机器的声卡输出节拍偏慢；若调制打开后仍有断字，见最后一条

你要做的

• 电台菜单 `SET` → `Connectors` → `MOD Input`：`DATA OFF MOD` = `USB`（语音模式用；想同时保留手咪就选 `MIC, USB`）、`DATA MOD` = `USB`（数据模式）、`USB MOD Level` ≈ 50（不要 0）。
• 同一组里 `USB SEND` 保持 `OFF`（IC-7300MK2 另见 `USB Keying (CW/RTTY)`）：它把 USB 口的 DTR/RTS 当作 PTT，设成 `USB(A) DTR/RTS` 后电脑一打开串口就等于按下 PTT。
• 改完按住 PTT 说话：网页面板上的 ALC 表必须动 —— 不动就是调制还是没进来；再用第二台接收机确认能听到语音。
• 麦克风电平：离嘴 5~10 cm 正常说话，避免长期 `peak=100%`（削波）或 1%（几乎无声）—— 本次两种极值都出现过
• 若仍有断字/断续：把 `MRRC_AUDIO_TX_DEVICE` 锁定为启动日志里 `default=48000Hz` 的 WASAPI 条目，或换 USB 口 / USB 线（本次 `queue_drops` 最高 226）

IC7300发射对方没有收到声音，测试用另外一台短波机收听也是听到发射但是没有声音

软件把语音送进了电台（52% 峰值的音频确证写进 USB 声卡），电台也真的在发射，但调制为零 —— 根因是电台侧的调制输入源没选 USB（`SET` → `Connectors` → `MOD Input`），不是音频链路故障

诊断

• PC→电台这一段是清的：`TX audio started: [5] 扬声器 (USB Audio CODEC ) (host=MME, default=44100Hz, actual=48000Hz, channels=1)`，随后 `TX session: frames=351 fed=351 decode_fail=0 written=228 write_err=0 queue_drops=110 peak=52%` —— `peak` 是服务端解码后 PCM 的实测峰值，52% 说明语音以正常电平写进了电台的 USB 声卡
• 对方听到的是「有载波、无调制」：本次电台在 FM 29.6 MHz（`Initial state: freq=29600000 mode=FM s_meter=6`），FM 的调制为零就是死载波 —— 与「听得到发射、听不到声音」完全吻合
• 唯一剩下的断点只能在电台内部：Icom 的 `SET` → `Connectors` → `MOD Input` 决定调制输入源，`DATA OFF MOD` 管非 DATA 模式（SSB / AM / FM 语音）、`DATA MOD` 管 DATA 模式、`USB MOD Level` 是 USB 输入电平；这一组不含 `USB` 时，网页里说的话不会进入调制器（电台用它自己的手咪当输入源）
• 这不是产品缺陷，但产品文档此前缺了这一节：FT-710 的等价要求（`MOD SOURCE = USB`）在操作指南与安装指南里都写着，Icom 的对应三条在全仓检索为零命中。本版已补进 `docs/OPERATION_GUIDE.md` §0.6.2 与 `docs/WINDOWS_INSTALLER_GUIDE.md`，并加了守卫测试防止再漏
• 次要观察（不改变结论）：本次 `queue_drops=110`，说明这台 Windows 机器的声卡输出节拍也偏慢；调制打开后若仍有断续，见最后一条

你要做的

• 电台菜单 `SET` → `Connectors` → `MOD Input`：`DATA OFF MOD` = `USB`（语音模式用；想同时保留手咪就选 `MIC, USB`）、`DATA MOD` = `USB`（数据模式）、`USB MOD Level` ≈ 50（不要 0）。
• 同一组里 `USB SEND` 保持 `OFF`（IC-7300MK2 另见 `USB Keying (CW/RTTY)`）：它把 USB 口的 DTR/RTS 当作 PTT，设成 `USB(A) DTR/RTS` 后电脑一打开串口就等于按下 PTT。
• 改完按住 PTT 说话：网页面板上的 ALC 表必须动 —— 不动就是调制还是没进来；再用第二台接收机确认能听到语音。
• 如果还有咔啦/断续：把 `MRRC_AUDIO_TX_DEVICE` 锁定为启动日志里 `default=48000Hz` 的那一条（WASAPI 条目），关掉不用的虚拟声卡（本机同时存在 ToDesk 虚拟声卡与立体声混音），或换一根 USB 线 / 另一个 USB 口 —— 本次 `queue_drops=110` 就是输出节拍跟不上的信号

没有开蒲公英，从外网进入https://bg7zhs.mrrc.vlsc.net/网页显示无法打开，更新md文件后显示网页出错，现在又显示无法打开网页

服务端本机是好的（8888 已监听 + SSL 已启用 + FT-710 CAT 已连上），公网打不开是入口通道问题——用户自己说"没有开蒲公英"；另外电台 USB 未枚举，导致 FT4222 频谱与 USB 声卡都不可用

诊断

• 公网入口不通 ≠ 服务未运行：stdout.log 显示本次启动完整成功——`SSL enabled: [已隐去]\AppData\Local\MRRC-Modern\certs\server.crt`、`MRRC Modern Web Control starting on port 8888`、`Connected to FT-710 (ID=0650) on [已隐去]`、10:30:03 仍在 `IF poll: vfo_a=7068000 Hz (loop=0)`，env.json 亦为 `"serial_connected": true`；用户在 problem.txt 里自述"没有开蒲公英"，所以 https://bg7zhs.mrrc.vlsc.net/ 无法打开是穿透/DNS 入口没起来，属网络环境问题
• `*.mrrc.vlsc.net` 不是本产品的配置项——本仓已有同一问题的公开答复（website/answers/index.html:46-62："`*.mrrc.vlsc.net` 不是本产品的配置项——产品只认 `MRRC_WEB_HOST`/端口 8888 和 `MRRC_SSL_CERT/KEY`"）；仓库全文检索 `mrrc.vlsc.net`/`bg7zhs` 只命中该答复页，代码里没有任何该域名的逻辑（公网收听入口是 www.vlsc.net/mrrc_modern/listen → 后端 radio.vlsc.net，与用户自建域名无关）
• 频谱回退与 Traceback/ERROR 是同一根因的下游噪声，不是崩溃：`scope_pipe: open_failed:attempt_1..5:error_2` → `spi_init_failed:all_attempts` → `fatal:cannot_open_device`（FT4222 设备枚举不到），scope_producer 按设计每 1s 自动重启管道（backends/ft710/scope_producer.py `_read_pipe` 末尾 `scope_pipe exited while active — will restart in 1s`），每次子进程退出都在 Windows Proactor 上产生 `Exception in callback _ProactorBasePipeTransport._call_connection_lost(None)`——体检摘要里 71 条 ERROR / 71 条 Traceback / 7055 条频谱命中都由此而来；日志尾部服务仍在正常轮询，没有致命异常
• 电台 USB 链路缺失（环境问题）：配置的收发声卡 `麦克风 (4- USB Audio Device)` / `扬声器 (4- USB Audio Device)` 在设备列表里不存在（`Configured audio device '麦克风 (4- USB Audio Device)' not found`，随后 `Using default audio input: [0] - Input`，即回落到 Realtek 主板声卡），FT4222 也 error_2；只有 [已隐去] 串口在——说明电台的 USB 口/线没接好，TX 时对方听到的不是电台音频
• server-prev.log 里 08:27–08:33 大量 `get_meter(RM8): unparseable response '<全 0/乱码>'` 也是同一 USB/串口链路不稳时期的产物；10:29 重启后 CAT 已恢复正常（ID=0650、频率读取成功），故不作为独立缺陷
• 历史比对：`open_failed:…:error_2` / `spi_init_failed` / `cannot_open_device` / `_ProactorBasePipeTransport._call_connection_lost` / `unparseable response` 在 CHANGELOG.md 与 SDD/14-version-history.md 中均无同签名条目（无既有回归记录），按环境/网络定性

你要做的

• 先把内网穿透客户端（蒲公英）启动并确认状态为"已连接"，再刷新 https://bg7zhs.mrrc.vlsc.net/ ；穿透没起来时该地址必然打不开，与 MRRC 无关
• 用局域网自证服务端正常：在同一网段的电脑/手机浏览器打开 `https://<这台Windows的局域网IP>:8888`（自签证书会告警，点"高级→继续访问"）。能打开即说明服务在跑，问题只在公网入口
• 核对穿透映射：外网端口要指向本机 **8888**、协议选 **HTTPS/TCP**（MRRC 是 https + WebSocket，HTTP 映射会白屏）；改完映射重启穿透客户端，并用 `nslookup bg7zhs.mrrc.vlsc.net` 确认域名解析到穿透给的地址
• 想不依赖穿透长期使用：路由器上把 8888 端口转发到这台机器，用自己的域名 + 真实证书（设置 `MRRC_SSL_CERT`/`MRRC_SSL_KEY` 指向 fullchain/key）；局域网内则直接用 `https://<本机IP>:8888`
• 接回电台 USB：现在只有 [已隐去] 串口枚举到，FT4222（频谱）与 "4- USB Audio Device"（电台声卡）都不在。检查 FT-710 的 USB 线/口与电台 MENU 的 USB 设置，在 Windows 设备管理器里应同时出现 USB Audio Device 与 FT4222/FTDI 设备；然后重启 MRRC Modern，瀑布图与真实频谱才会回来
• USB 声卡回来后，进"设备配置"把 RX/TX 音频设备重新选成实际存在的名字（当前配置项已失效并回落到 Realtek 默认设备，发射时对方听不到电台音频）；若暂时不接电台 USB，也请把配置改成现有设备名以消除启动告警
• 如果穿透起来后网页仍报错，请回报浏览器上的**完整错误文字/状态码**（例如 502 / 504 / ERR_TUNNEL_CONNECTION_FAILED / 证书告警）和穿透客户端日志——不同错误对应不同修法（映射端口错、后端超时、证书不受信）
• 顺带一提：env.json 显示 `"recording": {"active": true}`，若并非有意在录音，请在界面上停止录音，避免长时间占用磁盘

how to config the *.mrrc.vlsc.net? how can I make it work?

这台 Windows 机器上电台并未真正接上（串口不对/无 ID 响应、FT4222 找不到、没有任何音频设备），服务器只在『仅 UI』模式运行；`*.mrrc.vlsc.net` 不是本产品的配置项——产品只认 `MRRC_WEB_HOST`/端口 8888 和 `MRRC_SSL_CERT/KEY`。

诊断

• 核心不是域名配置，而是硬件没接上：日志显示串口 [已隐去] 打不开、唯一可用串口 [已隐去] 是主板通信口且无电台 ID 响应，FT4222 频谱设备、音频设备全部缺失，服务器退化为『Server will serve UI only』。
• 频谱签名 `scope_pipe: open_failed:attempt_N:error_2` → `spi_init_failed:all_attempts` → `fatal:cannot_open_device`：代码里 error 来自 FTDI `FT_OpenEx`，错误码 2 = FT_DEVICE_NOT_FOUND（scope_producer.py:70 注释明确提及），即 USB 上没有『FT4222 A』设备——电台 USB 线没接或驱动没装。
• 音频环境问题：`No audio input device found`，env.json 里 rx/tx 设备列表均为空 → 电台的 USB 声卡没枚举出来，属于环境缺失（非产品缺陷）。
• 串口环境问题：`Failed to connect to [已隐去]: ... FileNotFoundError`，可用端口仅 `[已隐去] (通信端口 ([已隐去]) ACPI\PNP0501\1)`；stdout.log 里 [已隐去] 能打开但 `No ID response from radio on [已隐去]` → 配置的 COM 口与电台实际口不一致或电台没接。
• Traceback 均为 `ConnectionResetError: [WinError 10054] 远程主机强迫关闭了一个现有的连接`，是浏览器/客户端断开 WS 的正常现象，不是崩溃。
• 域名方面：代码里产品域名固定为 `radio.vlsc.net`（config.py:196-199 SSL 注释与默认证书名），没有 `*.mrrc.vlsc.net` 相关逻辑；局域网访问走自签证书（ssl_bootstrap.py：为 LAN 用的 10 年自签证书，浏览器需信任一次）。

你要做的

• 用 USB 线把 FT-710 接到这台电脑并装好 Yaesu USB 驱动，让系统出现：电台串口（COM 口）、FTDI FT4222 设备、USB 音频设备。
• 在设备管理器确认电台实际枚举出的 COM 号，编辑 `[已隐去]\AppData\Local\MRRC-Modern\mrrc_modern.env`，把 `MRRC_SERIAL_PORT` 改为该 COM 号（当前日志显示配置 [已隐去] 不存在、[已隐去] 无响应），然后重启服务。
• 确认音频：接好线后系统出现 USB 音频设备；env 里 `MRRC_AUDIO_RX_DEVICE`/`MRRC_AUDIO_TX_DEVICE` 留空走自动检测，或填设备名。
• 域名访问：本产品不提供 `*.mrrc.vlsc.net`。局域网内直接用 `https://<本机IP>:8888`（默认绑定 `::`，可用 `MRRC_WEB_HOST` 改）；想用自己的域名需自行做 DNS 解析 + 路由器端口转发 8888 + 用 `MRRC_SSL_CERT`/`MRRC_SSL_KEY` 指向真实证书（如 Let's Encrypt fullchain）。
• 浏览器首次访问自签证书会有『不受信任』警告，接受一次即可；若走真证书则不会有警告。
• 日志里的 WinError 10054 Traceback 可忽略，不影响使用。

analysis the logs

FT-710 未通过 USB 正确连上电脑（CAT 串口、FT4222 频谱、USB 音频三路同时缺失），属环境/连接问题，非产品缺陷

诊断

• 频谱 FT4222 打不开：日志反复出现 `scope_pipe: open_failed:attempt_N:error_2`（N=1..5），随后 `spi_init_failed:all_attempts` + `fatal:cannot_open_device`，`scope_pipe exited (frames=0, connected=False)` 每 1s 无限重启。依据 scope_pipe.py 的 open_device()：用 `d2xx.FT_OpenEx(desc, FT_OPEN_BY_DESCRIPTION, ...)` 按描述 "FT4222 A" 打开设备，返回非 FT_OK 时打印 `open_failed:attempt_{N}:error_{s}`——error_2 即 D2XX 状态码 2 = FT_DEVICE_NOT_FOUND，说明 FT4222 设备根本未在 USB 上枚举到
• 音频缺失：`No audio input device found`，env.json 中 `audio.devices.rx: []`、`audio.devices.tx: []`，configured_rx/tx 均为空——电台的 USB 声卡也没出现
• CAT 无响应：`No ID response from radio on [已隐去]. Check connection.`，串口配置为 [已隐去]@38400（[已隐去] 通常是物理/旧串口而非 FT-710 的虚拟串口），serial_connected 仅表示端口能打开，不代表电台应答
• `ConnectionResetError: [WinError 10054]` 是浏览器/客户端断开连接导致的 asyncio 回调异常，非崩溃，可忽略

你要做的

• 确认 FT-710 已开机，并用数据 USB 线（非仅充电线）连接到这台 Windows 电脑
• 打开设备管理器检查三样东西是否出现且无黄色感叹号：端口(COM 和 LPT) 下的 USB Serial、通用串行总线下的 "FT4222 A"、音频输入/输出下的 USB Audio CODEC；缺失则安装 FTDI D2XX/FT4222 驱动后重插
• 在配置文件 mrrc_modern.env（[已隐去]\AppData\Local\MRRC-Modern\mrrc_modern.env）中把串口改成电台实际占用的 COM 口（当前写的是 [已隐去]），或删掉 MRRC_SERIAL_PORT 后重开让程序重新识别
• 确认没有其他程序（WSJT-X、Hamlib、另一个 MRRC 实例）占用该 COM 口或 FT4222 设备
• 改好后重启应用；WinError 10054 只是浏览器页签断开，无需处理

(未填写)

无在发产品缺陷：录音「dropped/queue full」签名与 V2.44/V2.45（v1.15.0 发布）修复的写入端生命周期缺陷同签名，但均为 2026-09-12 旧日志、当前 v1.18.1 已含修复（server.py:348 `_ensure_rec_writer()` 幂等重建 writer、server.py:432 队列满改为丢最旧块），09-19 近期日志录音/音频/串口全部健康；其余命中为 USB 串口重枚举（环境）与开发机跑测试套件写同一日志造成的 Traceback 误报

诊断

• 录音命中全部是 2026-09-12 22:30 的旧日志（summary.txt『== 录音写入：233 条 ==』首条 2026-09-12 22:30:23,503 『Recording dropped 350 block(s) so far』、22:30:24,151 『Recording queue full on stop — finishing directly』），与 SDD/14-version-history.md V2.44/V2.45 记录的 22:26 现场签名（dropped 950 块 + queue full on stop + 时长正确全静音）同源，该缺陷在 v1.15.0 已修复，当前 1.18.1 远高于修复版本 → 按已修复的历史残留处理，非回归：2026-09-19 的 server.log 尾部无任何录音告警，env.json 显示 recording.active=true 正常
• 『串口掉线 5335 条』为 [Errno 6] Device not configured 的 USB 桥重枚举（summary.txt『串口恢复：出现 ENXIO…』），日志原文已指明电缆/供电/无源 HUB 嫌疑，且均发生在 2026-09-12；09-19 近期日志 serial_connected=True、IF poll 每约 5 分钟一次干净返回（『2026-09-19 08:55:14,656 IF poll: vfo_a=7060000 Hz (+0 Hz)』），属环境问题非缺陷
• 『Traceback 47 条 + 启动 25 次 ⚠️崩溃』是误报：server-prev.log 尾部大量行是单元测试输出（/dev/fake 端口、tmp 路径、『test_cq_player.py:162』『test_memory_recall.py:66』等），即本机在仓库目录跑测试套件时与服务器共用 logs/server*.log，测试的 Traceback 被计入体检；09-19 真实服务器会话（08:13–08:55）无异常，TX 会话 frames/written 正常、queue_drops=0
• 音频『Configured audio device not found』与『RX open failed -9999』均为 09-12/09-18 旧记录，对应设备重枚举后缓存索引失效（AGENTS.md 已记载该已知行为并带重初始化恢复）；09-19 日志显示『RX audio started: [4] USB Audio Device』反复成功
• 『Weak password detected!』（2026-09-19 08:55:07,770）为使用建议；『未验证机型拒绝发射』TX 门禁 141 条属预期安全行为（env.json tx_gated=false，实际在用 FT-710 未被门禁）

你要做的

• 若近期再次遇到录音无声：直接重新录一段并用播放器确认，当前版本已按会话重建写入器；如新录音仍全静音再上报并注明时间点
• 串口若再掉线：把 FT-710 USB 线直插主机（不用无源 HUB），换一根短一点的优质 USB 线，并确认电台供电稳定；掉线后服务器会自动重连，无需重启
• 设备重插后若提示『Configured audio device not found』：在设置里重新选择当前的 USB Audio 设备名保存即可（系统重枚举会改变设备序号，程序已按名称解析）
• 建议把测试/开发运行的服务端日志与日常使用的 MRRC_LOG_DIR 分开（例如日常启动器已指向用户数据目录），避免测试 Traceback 污染体检摘要
• 把 Web 登录密码改为至少 12 位、含大小写/数字/符号，消除 Weak password 告警
• 如需 IC-705/IC-7760 等未验证机型发射，先按日志提示用 _diag_civ.py 核验电台，再设 MRRC_ALLOW_UNVERIFIED_TX=1 并重启；对 FT-710 无影响，可忽略该告警

相关代码：server.py:348 _ensure_rec_writer（V2.44/V2.45 修复已存在，当代码无需改动）

(未填写)

录音签名与 V2.44/V2.45 修复的「写入端一次性生命周期」缺陷同签名，当前 v1.18.1 已包含修复；包内命中行全部为 2026-09-12 修复前的历史日志，9/18 当天无新录音丢弃，按回归排查（用户先做一次新录音验证），其余告警（串口 ENXIO、音频 -9999、TX 门禁、弱密码）均为已知环境/预期行为

诊断

• 录音签名逐行吻合本仓历史：`Recording dropped 350 block(s) so far` + `Recording queue full on stop — finishing directly` 与 V2.44/V2.45（v1.15.0 发布，2026-09-12）记录并修复的『MP3 writer 只在进程启动时创建一次，首次 REC/STOP 后每会话无人消费、时长正确内容全静音』缺陷完全同签名；当前代码已含修复（server.py:348 `_ensure_rec_writer()` 在每次 add_audio/stop/REC 幂等重建 writer，队列满改为丢最旧块）→ 按回归排查：包内该签名的样本行时间戳均为 2026-09-12 22:30/22:37（修复发布前的旧日志残留），而 2026-09-18 当天的 log 尾部零条录音丢弃，故需用户在 1.18.1 上录一段新 QSO 验证；若新录音仍全静音即为回归
• 串口掉线 6893 条：`[Errno 6] Device not configured` + `No such file or directory: [已隐去]` 为 USB 串口桥物理层消失后重枚举（V2.43 已优化恢复成本：重连不再做 17 s 的全量状态同步），属线缆/HUB/供电环境问题，非产品缺陷
• 音频恢复 192 条：`RX open failed ([Errno -9999] Unanticipated host error)` 是 macOS Core Audio 在 USB 重枚举后缓存设备索引失效的已知现象，产品已内置 PortAudio 重初始化 + 按设备名重解析重试（audio_handler.py）；`Configured audio device 'USB Audio Device' not found` 与之同源，env.json 显示当前两设备均已枚举到，属瞬时环境问题
• TX 门禁 141 条（IC-705/IC-7760/FTDX10 not hardware-verified — transmit refused）为预期安全行为，且本机 radio.model=ft710、tx_gated=false，不影响使用；`Weak password detected!` 为密码强度提醒
• Traceback 47 条在包内未附任何堆栈内容（仅重复标题行），且 server-prev.log 显示本机同时跑过单元测试（tests/test_cq_player.py 等），无法归因到运行故障；如需排查需附原始堆栈段落

你要做的

• 录音回归验证：在 v1.18.1 上开启一次录音（REC）→ 收发几十秒 → 停止，回放生成的 MP3 确认有声音；本仓 recordings 目录文件名含频率与时间（如 `<freq>kHz_<日期>_<时间>.mp3`），若新录音正常则说明包内命中只是 9/12 的旧日志，无需处理；若仍全静音，再上报并注明新录音的文件名与时间
• 串口稳定性：电台 USB 线直连电脑、不经无源 HUB；换一根短一点的优质 USB 线；确认电台供电稳定（重枚举多由供电/接触引起）；掉线后程序会自动重连并经轮询层级恢复状态，无需手动重启
• 音频无声/启动时 RX 打不开：电台断电重开或换 USB 口后，在设置里重新选择 RX/TX 设备（macOS 重枚举会改变设备序号，程序会按名称重解析，但设备被系统改名/占用时需手动重选）并重启服务
• 如确需在未验证机型上发射才设置 MRRC_ALLOW_UNVERIFIED_TX=1（先用 _diag_civ.py 验证电台），本例 FT-710 已验证、无需设置
• 按提醒把 Web 登录密码改为 ≥12 位、含大小写/数字/符号的强密码

相关代码：server.py:_ensure_rec_writer（修复已在当代码；如复现回归再查 recorder.py:_recording_writer_loop 与 server.py 的 _rec_queue 消费端）