TUIC 节点不通：旧版 issue 873 记录了什么
历史 issue 描述升级到 v1.17.0 后 TUIC 失败，讨论还涉及 v1.18 和 v1.18.1。用户变通办法的反馈并不一致；记录中没有维护者回复或代码修复，不能由此确定当前版本的处理方式。
哪些版本出现在报告里？
报告者说从可用旧构建升级到 v1.17.0 后遇到问题。 标题写的是 1.17 版本 TUIC 节点不通，而 vless ws 正常。这一差异属于报告者的场景。
issue 编号为 873，提出于 2023-12-05，2024-02-19 以 completed 关闭，带有 bug 标签。版本、提出时间与关闭状态分别记录，不把它们组合成某次发布已经修复的说明。
| 信息 | 历史记录 |
|---|---|
| 报告升级版本 | v1.17.0 |
| 后续用户提到 | v1.18、v1.18.1 |
| 服务端自述 | sing-box 1.7.2 |
| 当前版本适用情况 | 官方没有说明 |
日志出现了什么内容？
日志记录 TCP 拨号错误，内有 INTERNAL_ERROR 与 sendmsg invalid argument。 这些文字对应帖子中的错误现象。不能只看到相同日志词语，就认定你现在的问题必定与这条旧记录相同。
报告者写明 TUIC 服务端使用 sing-box 1.7.2，后续用户又称 v1.18 和 v1.18.1 仍有问题。客户端与服务端版本有各自上下文，不能把其中一项当成另一项的版本。
日志只用于辨认讨论涉及的现象，没有转化成可直接使用的连接配置，也没有补未说明的测试结果。
评论中的办法都有效吗？
用户反馈不一致，不能整理成所有环境都适用的办法。 有人报告设置 experimental 下的 quic-go-disable-ecn 为 true 有效，报告者也确认有效。但还有评论说部分环境仍然无效，这部分反馈同样保留。
另有用户尝试 skip-cert-verify，反馈没有作用。
变通办法同时存在有效与无效反馈，不能只保留其中一边。
当前版本是否仍需要这些改动，官方没有说明，不能从旧评论增加新的操作要求。
completed 能证明什么？
它能说明 issue 的关闭状态，不能代替没有记录的代码修复。 帖子没有维护者回复，也没有记录修复代码。
| 页面信息 | 不应扩展成的判断 |
|---|---|
| bug 标签 | 已确定全部根因 |
| completed 状态 | 修复已随某版发布 |
| 用户反馈有效 | 所有环境适用 |
| 后续版本仍有人报告 | 所有用户都受影响 |
这些区分用于保留历史记录本来的范围。它们没有提供当前客户端的完整诊断。
官方配置说明读到了吗？
TUIC 与 experimental 的正式配置文档，官方没有说明。 这里没有取得对应选项的完整解释，不从其他项目文档补默认值或适用版本。旧帖子出现配置名称，不等于它们在当前版本仍以同样方式提供。
这条旧记录可按以下内容核对：
- 看客户端与服务端的版本，不将两类数字互换。
- 对照有效和无效反馈，不遗漏任一边。
- 看是否记录了维护者回复及代码修复，不把状态当成发布记录。
若要继续了解配置与节点问题，可看 节点连接排查资料，其他概念可看 客户端问题说明。
阅读时可先看版本与日期，再区分报告者自述、其他用户反馈和项目处理记录。这个顺序只是整理旧讨论，没有写成官方检查步骤，也没有把历史问题改写为当前所有 TUIC 节点的共同情况。
历史记录不能替代当前版本说明。
核对状态：依据：官方文档与通用说明 · 最近核对 2026-11-01