CLIENT ADERPCLIENT BTLS · 双向消息验证
案例示意 · 非运行截图TLS / ACCESS CONTROL01遇到的问题
部署中继之后，怎样确认连接身份、消息内容和准入失效时的行为？这次实验从这些问题出发，在正常转发之外，也把拒绝连接与服务恢复纳入测试。
怎么推进
实验先确认域名解析和 TLS 入口，再设置节点公钥白名单。随后用两个逻辑客户端校验双向消息，并依次测试未登记身份、准入服务停机和服务恢复后的新连接。
结果与收获
登记节点能够转发消息；未登记节点被拒绝。准入服务停机时，新连接没有被默认放行；恢复服务后，双向转发再次通过校验。
我的参与与协作分工
我提供 VPS 和域名，完成 DNS 指向；构建、服务配置、测试程序与测试执行由 Codex 完成。
换一个场景，看准入行为
测试记录演示 · 非实时实验客户端 ADERP实验客户端 B
允许握手并转发消息
双向每方向 20 条、每条 1 KiB，校验来源与内容一致。
这是两个逻辑协议客户端，不是两台真实 Tailscale 设备。测试记录 · 范围说明 +
- 基于官方 Tailscale v1.104.1 模块的构建记录
- 每方向 20 条、每条 1 KiB，双向共 40 条内容一致
- 未登记节点拒绝、准入停机拒绝与恢复后复测记录
本次协议实验使用同一台 Mac 上的两个逻辑客户端，覆盖公网 TLS 连接、消息转发与新连接准入。测试不包含真实 Tailscale 设备的业务选路，未开启 STUN，结果不代表吞吐性能或长期可用率。页面交互演示测试行为，不读取服务器实时状态。
下载脱敏实验记录 ↓CASE 05 / 服务与自动化脚本实现与规则测试
Docker 异常监控
正常等待，不必被打扰
容器显示 running，里面的任务却未必正常推进。为此增加独立看门狗，结合运行状态、错误日志和业务进度判断异常，同时把扫码、排队等正常等待单独处理。
CONTAINER RUNNING检查任务，而不只是进程。 案例示意 · 非运行截图OBSERVABILITY / ALERTS01遇到的问题
自动化任务并非一直有新进度：扫码和排队都可能让日志暂时停下来。如果只看容器是否运行，容易漏掉故障；如果把所有静默都判为卡死，又会误报正常等待。
怎么推进
监控结合容器状态、重启次数、错误日志与业务活动进行判断，对异常通知去重，并在恢复后补发消息。疑似卡死只告警；容器已经停止，则按脚本配置尝试启动。
结果与收获
监控能够区分异常与正常等待，对同一异常去重提醒，并在恢复后单独通知。错误、退出、恢复和正常等待等场景均有测试摘要，配套保留脚本与 systemd 单元。
我的参与与协作分工
我提出异常提醒、防误报和疑似卡死时只告警的要求，并参与规则讨论；脚本编写、部署和测试有 Codex 协助。
这个状态，应该怎么处理？
规则示意 · 不读取容器现有监控规则业务状态判断
等待本身不触发告警
容器仍在运行，日志显示等待扫码或排队，且没有明确的超时或错误记录。
处理方式将其视为合法等待；不因暂时没有游戏进度就重启容器或发送卡死告警。
一旦出现排队超时、登录超时等明确错误，仍应进入错误告警路径。代码与测试 · 范围说明 +
- 保存的看门狗源码与 systemd 单元
- 错误、退出、恢复和正常等待的测试摘要
- 交互演示现有监控规则，以及独立的时长提醒设计
本案例介绍已有监控脚本与规则测试，代码实现包含 Codex 协助。测试记录不包含整体误报率测量，也不代表服务器当前运行状态。页面演示不读取容器、不发送通知；时长提醒为设计展示，不属于已部署的监控功能。