iSCSI服务端重启后客户端卡在重新连接，target侧怎么查
Windows Server 2019做iSCSI target，初次连接一切正常，业务也跑得稳；某天服务器例行重启，发起端那边就一直停在"正在重新连接"。服务看着还在，IP也没变，客户端反复刷新也没用。这类故障有个典型特征：配置从头到尾没人动过，坏的是"重启之后能不能自动回到可服务状态"。
原因分析
初次能连、重启后连不回，说明iSCSI的配置本身没问题，排查重点应当放在target这一侧，而不是急着在客户端重装发起程序。服务端重启后回不到可服务状态，常见断点有三处：
一是target服务没有随系统自启。iSCSI目标服务如果是"手动"或"触发启动"类型，重启后没人拉它起来，3260端口无人监听，客户端自然一直在重连。
二是防火墙换了副面孔。Windows防火墙规则跟着网络配置文件走：重启后如果网卡被识别成"公用网络"，而当初放行3260的规则只绑在"专用网络"上，规则看着还在、实际不生效。
三是监听地址漂移。target绑定的IP若靠DHCP获取，重启后换了地址，发起端记着的还是旧IP；同理，改过主机名或重装过target组件后IQN变了，发起端按老IQN找人也是白找。
分步解决
- 确认target服务自启。服务器管理器里查看iSCSI目标服务器相关服务的启动类型，改成"自动"，并当场重启一次服务验证能正常回到运行状态。相当一部分"重启后连不回"到这里就结案。
- 核对防火墙配置文件。防火墙高级设置里找到放行3260端口的规则，看"作用域"里的网络配置文件是不是只勾了专用。把规则指向所有配置文件，或者干脆把这台服务器的网卡网络类别固定下来，避免重启后被重新识别成公用网络。
- 盯住监听地址。生产环境的iSCSI服务端用静态IP，iSCSI流量与业务流量分网段，能分物理网卡更好。检查target当前绑定的IP与发起端配置里填的地址是否一致。
- 核对IQN与凭据。事件查看器里翻iSCSI相关日志，能直接区分是认证失败还是连接超时：认证失败查CHAP凭据和IQN是否变化，连接超时查网络层。比在客户端盲猜快得多。
- 服务端逐项确认后再回客户端。在服务端用命令确认3260端口处于监听状态，再从发起端测一下该端口的连通性——通而认证不过，查凭据；不通，回查防火墙和网段。客户端侧做一次断开会话、重新登录即可，网上教程很多，但服务端没回到可连接状态之前，客户端怎么点都是徒劳。
预防
诚鑫致达科技维护iSCSI环境有个约定：动target之前先给所有发起端发一句下线通知，改完再逐台挂回验证——服务端一次计划内的重启，不该演变成客户端一整天的重连。变更单上把"通知发起端、重启、逐台验证"写成固定三行，谁执行都照单走，target侧的会话恢复就有了兜底。