Tailscale 于 2026 年 9 月 24 日发布容器镜像 v1.102.5，修复一种 Tailscale 容器异常退出情形：状态更新处理滞后、连接被关闭后，容器原先会停止 tailscaled。新行为是尝试重新连接，仅在一分钟内无法重连时退出。官方指出该情形在大型 tailnet 中较常见，详见官方更新日志的 9 月 24 日条目。
如果你通过 Tailscale 容器维护自有服务器或内部服务，且退出前的日志与上述条件相符，可优先安排 v1.102.5 升级核验。本文的建议是：先记录故障时间和现有镜像，再确认状态卷，最后分别检查容器运行、节点身份及业务访问。本次公告针对容器镜像，没有列出完整受影响旧版本范围，不能据此判定所有旧客户端都存在同一问题。
先判断：你的故障是否落在本次修复范围
“远程访问失败”只是结果，排查时应先问：退出的是 Tailscale 容器、应用容器，还是两者仍在运行但访问超时？建议把容器退出时间、宿主机事件及当时日志放在同一条时间线上。若只有浏览器打不开页面，没有进程退出或相关状态更新异常证据，应继续查证，避免把新版本号当作故障结论。
- 优先评估升级：使用 Tailscale 容器，且有与官方描述相符的退出记录。
- 安排常规维护：部署暂时稳定，可以先在非关键实例检查镜像和配置，再计划替换。
- 继续定位：应用自身退出、宿主机资源不足或访问权限变更，应沿各自证据调查。
以上是编辑排障建议，不是官方对某个读者环境的诊断。尤其不要仅凭 tailnet 节点数量多就确定命中问题；官方没有给出“大型”的数字门槛，也未承诺升级后所有业务连接持续不中断。
涉及办公内网时，应由有权限的管理员执行检查。网络连通和业务授权是两个需要分别核验的条件，可结合公司远程办公 VPN 的内网路由与权限边界说明确定测试范围。
升级前：保留节点身份，建立可比较的记录
先记下实际运行的镜像和故障基线
记录部署清单中的镜像引用、运行实例的镜像标识、上次启动时间和退出记录。建议同时保存一份不含密钥的配置摘要，写明网络模式、挂载位置及所承担的服务角色。这样升级后若现象改变，才有依据判断是镜像替换还是同时改动配置造成。
从官方更新日志提供的镜像仓库入口核对发行物。本文讨论的是容器镜像 v1.102.5，不能把其他平台的软件包、编排组件版本或宿主机客户端版本当成容器已经升级的证据。执行替换前，应准备能独立于该容器使用的管理通道。
核对状态目录是否真的持久化
官方Docker configuration parameters 文档说明，TS_STATE_DIR 指定状态存储目录，持久化该目录用于在重启间保留容器身份。检查时应同时看变量指向和实际卷挂载，而不是只看到配置中有目录名就认为状态已保存。
编辑建议是在维护前确认备份与恢复方案，并保护状态文件和认证信息。不要为了“重新连一次”先删除卷或清空身份状态；这会引入新的变量，使升级前后的节点难以对应。不同编排方式的状态存储可能不同，不应把本地 Docker 卷的做法直接套用到所有 Kubernetes 部署。
同一官方参数页说明，TS_AUTH_ONCE=true 表示仅在尚未认证时登录，默认值为 false。对已经持久化状态的部署，可核对这一设置是否符合原有登录策略。它控制登录行为，不能代替本次容器修复，也不应作为无条件照抄的参数。
升级后的验证清单：进程、身份、业务分开验收
以下步骤是建议的维护验收流程，不代表本站已对你的环境进行实测。先选择可接受中断的实例，保留原配置，仅替换目标镜像；观察范围应覆盖此前容易出现故障的使用场景，而不是看到启动成功就结束。
- 确认替换生效：核对运行实例对应的镜像标识和部署记录，避免只修改清单却仍运行旧实例。
- 检查运行连续性：记录升级后的启动时间、退出事件和日志时间线，关注之前的故障征兆是否再次出现。
- 核对节点身份：检查管理界面中的节点是否与预期一致。若出现新节点，先检查状态存储和挂载，再分析网络故障。
- 验证实际业务：从获授权的另一台设备访问原有内部服务，分别记录名称解析、连接建立及应用响应结果。
- 保存比较结果：写明旧现象、替换时间、观察条件与结果。若再次退出，保留退出前后的日志，并按既定变更流程决定继续调查或回退。
不要为了复现问题，在生产环境主动制造大规模状态更新或中断关键管理连接。没有再次出现异常，只能说明在本次观察条件下未复现；如果此前故障间隔很长，短暂观察不足以证明已经排除。
为什么健康检查通过还要访问业务
官方参数文档规定，启用 TS_ENABLE_HEALTH_CHECK 后，/healthz 在节点至少有一个 tailnet IP 时返回 200，否则返回 503。这个判定条件不包含你要访问的应用是否正常响应。详情可核对健康检查参数说明；因此，业务访问必须单独验收。
如果容器持续运行，但只有内部域名访问失败，应保留名称解析结果，转向 DNS 证据。并用 Mihomo 的读者可参考Mihomo 与 Tailscale 分域 DNS 故障核验，但不要把那个问题与本次容器退出混为一谈。如果解析正常而流量去向不符，可再查代理规则匹配顺序与分流排查。
常见问题
v1.102.5 是否修复所有 Tailscale 掉线？
不能这样判断。9 月 24 日官方条目限定了容器状态更新滞后与连接关闭的条件。应用故障、路由和权限等问题仍需各自的证据；只有症状相符，才有理由把该修复列为优先验证项。
一分钟重连是否意味着业务一定在一分钟内恢复？
不是。官方描述的是容器在无法重连时退出的条件，没有给出端到端业务恢复承诺。维护验收应记录实际业务响应，不能把容器内部的等待时间当成应用可用性指标。
升级后出现一个新节点，应该继续删除重建吗？
建议先停下重复重建，核对状态目录和持久化挂载。官方文档明确将状态持久化与身份保留关联；先保存证据、确认旧状态是否仍在，再按部署流程处理，避免使身份变化更难追溯。
健康检查返回 200，可以结束排障吗？
还需要验证目标服务。官方定义的成功条件是节点具有 tailnet IP，而你的验收目标是获授权设备能够完成指定业务访问。两者回答的问题不同，应分别记录结果。
官方来源与核验入口
- Tailscale — Changelog；相关更新日期：2026 年 9 月 24 日；核验日期：2026 年 9 月 27 日。查阅 Tailscale container image v1.102.5 修复说明与官方镜像入口。
- Tailscale — Docker configuration parameters；页面标注 Last validated：2026 年 3 月 23 日，该日期不是本次发行日期；核验日期：2026 年 9 月 27 日。核对状态目录、登录行为及健康检查参数。
关于作者
