screen状态为Attached却连不上，应使用screen -D -r <session-id>强制踢出旧连接并重连，该命令先发送detach请求使会话转为Detached状态，再立即接管，成功率接近100%。
screen -ls 显示 Attached 却连不上
这是 screen 最典型的“假连接”状态：会话被标记为 Attached，但实际没人正在使用它——比如你上次 SSH 断连、终端被强制关闭、或误按 Ctrl+A+k 后又没清干净。此时 screen -r session_name 会直接报错：There is no screen to be resumed matching xxx，因为 -r 只认 Detached 状态。
用 screen -D -r 强制踢掉并重连
核心动作就是「先断开（-D），再重连（-r）」，一步到位。这个组合命令会主动向当前占用该会话的客户端发送 detach 请求，哪怕对方已失联，也能把会话状态从 Attached 切成 Detached，然后立即接管。
- 先运行
screen -ls找出目标会话，例如输出中有：12345.mysession (Attached) - 执行
screen -D -r 12345.mysession或简写为screen -D -r mysession - 终端会短暂卡顿或闪退一次（这是正常现象，表示旧连接被强制中断）
- 重新登录后，再运行
screen -r mysession就能进去了
为什么不用 screen -d 单独 detach？
screen -d session_name 确实能把 Attached 变成 Detached，但它只起“通知”作用——如果原连接还活着（比如另一个 SSH 标签页开着），-d 会失败或无响应；而 -D -r 是带强制语义的，等价于「先发 SIGTERM 给旧 client，再立刻 bind 新 terminal」。
-
screen -d mysession在对方已掉线时可能静默成功，但无法保证 -
screen -D -r mysession不依赖旧连接是否存活，成功率接近 100% - 不要用
screen -S mysession -X quit，那是直接杀进程，会终止里面所有任务
容易忽略的细节和边界情况
真实环境里，Attached 状态卡住往往不是孤立问题，而是连锁反应的结果。
- 多个同名会话存在时（比如反复
screen -S job没清理），screen -D -r job可能随机匹配其中一个，建议优先用完整 ID（如12345.job） - 如果
screen -D -r执行后提示No screen to be resumed，说明该会话其实已被销毁，只是 socket 文件残留，此时运行screen -wipe清理元数据 - 长期无人维护的服务器上，/run/screen/S-$USER 目录权限可能异常，导致 detach 失败，可临时加
sudo（但不推荐作为常态方案）
