昨晚跑一个MS17-010的永恒之蓝漏洞，exploit打过去，shell死活弹不回来。终端卡在“Meterpreter session 1 opened”那行，光标一直闪，跟死机似的。等了五分钟，我直接Ctrl+C了。

这种卡住太常见了。不是网络断了，也不是目标机崩了，而是payload和handler之间没握上手。session显示opened，但实际是假连接——TCP握手完成了，meterpreter的初始化数据没传完。你看着像卡住，其实是卡在staging阶段。

我后来查了下，八成是防火墙把后续的TCP流量拦了。永恒之蓝打的是445端口，但meterpreter的reverse tcp默认走4444，很多企业防火墙对出站端口有白名单。你第一次连接能建立，是因为漏洞利用本身走的是SMB协议，防火墙放行了；但后续的payload回连走4444，就被拦在半路。这玩意儿不是exploit的问题，是网络策略的问题。

还有一种情况更坑——目标机器是多网卡主机。payload回连的IP地址写错了，或者路由表有问题，导致数据包发到了错误的网卡上。你看到session opened，但实际数据全丢在黑盒子里。这种情况你换什么payload都没用，得先确认目标机的路由。

再有一种，纯粹是目标机性能太差。老旧的Windows XP或2003，CPU占用率本来就高，meterpreter的stager跑起来要分配内存、加载dll，慢得跟幻灯片似的。有时候你以为卡住了，其实过个两三分钟它自己会好。我建议你等够90秒再动手，别急着打断。

但最烦人的是，卡住之后整个msfconsole也变卡了。输入命令没反应，按回车要等好几秒。这是msf的job线程被阻塞了，不是网络问题。这时候别硬等，直接开个新终端，用jobs -k把卡住的job杀了，重新跑一遍。或者干脆退出msfconsole，重开一个，省得内存里残留一堆僵尸线程。

要是你用的是windows payload，可以试试换成windows/x64/meterpreter/reverse_tcp_rc4，用RC4加密通信，很多IDS/IPS对这种流量识别率低，能绕过部分拦截。但注意，目标必须是64位系统，32位的机器直接报错。

最后说个土办法——把payload换成windows/meterpreter/reverse_http，走80端口。HTTP协议穿透性比TCP强，很多防火墙默认放行80。虽然速度慢点，但至少能拿到session。我上次用这个方法救回一个卡了半小时的shell，虽然延迟高得想砸键盘，但总比没有强。

exploit卡住不是世界末日。先看网络，再看系统，最后换payload。别死磕一个姿势，灵活点，meterpreter这玩意儿本来就是多个方案轮着试。