已删除的 ZeroTier 成员又回来了：先撤销授权

你删除了成员、关掉页面，一天后同一台设备又出现了。这不是控制台的缺陷。当设备仍在线、仍在申请加入时删除记录，就会出现这种情况。

两项操作紧挨在一起，但职责不同。一项决定访问权限，另一项只是整理列表。

从再次出现的记录入手

打开网络，查看回来的那条记录。记下它的 node ID、最后一个地址以及它再次出现的时间。把它与你想退役的设备对照。显示名称是别人输入的，地址也可能在下一次加入时变化。

node ID 才是稳定的标识。网络 ID 只给网络命名，它只告诉你正在看哪份列表，却不说明里面有哪台设备。两样都记下来，再把 node ID 与你想退役的那台机器对上。

这一步比对错了，你会移除一台仍在工作的机器，而不想要的设备还在继续申请。列表随后会有一天看起来是对的。这一天足够没人察觉，而这正是问题所在。

先撤销，再删除

先通过控制器支持的工作流更改授权状态。从那一刻起，加入尝试会显示为未授权，而不是悄悄恢复访问；请求是可见的，而不是隐形的。

删除在后，绝不代替撤销。删掉一条已授权成员的记录，就没有东西可撤销了。设备会再问一次，控制器会把它当作新设备。

对于仍在你掌控中的机器，退出网络是退役的有用一环。它不能代替管理员对丢失设备所做的决定。不再受你控制的客户端可以无视任何告知。

两项操作分别在哪里

在托管控制器上，成员列表同时提供这两个动作，并且标注得足够清楚以区分。在自托管控制器上，同样的区别出现在 API 和本地配置里，混乱通常就从这里开始。

# list members with authorization state
curl -s -H "X-ZT1-Auth: $TOKEN" \
  "http://127.0.0.1:9993/controller/network/$NETWORK_ID/member" | jq 'to_entries[] | {id: .key, authorized: .value.authorized}'

# deauthorize one member by node id, then confirm
curl -s -X POST -H "X-ZT1-Auth: $TOKEN" -d '{"authorized": false}' \
  "http://127.0.0.1:9993/controller/network/$NETWORK_ID/member/$NODE_ID"

这两次调用足以说明成员是否真的曾经处于未授权状态。带着 authorized: true 反复回来的记录，从未被撤销过，只是被删除了。

从资源验证，而不是从列表

整齐的成员列表不是访问检查。用那台设备、或用持有它旧地址的机器，去试它以前用过的资源，确认连接失败。然后再确认获准的替代设备仍然可用。

这项测试要包含路由与服务权限。ZeroTier 可以授权某个成员，却仍让它无法到达受管路由。应用权限也可能以同样的方式失败。从成员列表上看，两者完全一样。

zerotier-cli listnetworks
ip route show | grep zt
ping -c 3 10.144.0.5

自托管控制器要保留其身份与配置的一致备份。回滚到较早状态的恢复会把旧授权一并带回来，成员列表看上去会和退役前一模一样。

当旧身份无法到达任何东西、记录也已消失时，退役才算完成。按这个顺序做，成员就不会再回来。