最核心判断依据是观察syn是否发出及有无对应响应：若无syn，说明应用层未发起连接；若有syn无syn-ack，多为网络路径阻断或目标未监听；若收到rst，则明确被拒绝；若收到syn-ack却无ack，表明本地协议栈异常拒绝。
直接看syn发出去有没有回，是分析windows终端握手失败最核心的判断依据。wireshark不是用来“猜问题”的，而是让你亲眼看到连接在哪个环节断掉——是根本没发出去，还是发了没人应，还是应了但被拒绝。
确认抓包环境是否真实捕获到终端流量
很多失败分析卡在第一步：你根本没抓到目标报文。Windows终端（如telnet、PowerShell Invoke-WebRequest、或自研客户端）发起TCP连接时，必须确保Wireshark正在监听正确的网卡，并且该网卡确实承载了这次通信。
- 打开Wireshark → Capture → Interfaces，只勾选你电脑与目标服务器直连的那块网卡（比如以太网2，而不是Wi-Fi或虚拟网卡）
- 勾选“Promiscuous mode”（混杂模式），尤其当终端和目标在交换机后、或使用NAT/代理时，避免漏掉非本机MAC地址的报文
- 启动抓包后，再执行终端命令（例如：telnet 192.168.1.100 8080），不要提前开始、也不要延迟停止
- 停止抓包后，立即用显示过滤器 ip.addr == 192.168.1.100 and tcp.port == 8080 快速聚焦
识别三次握手各阶段的典型失败报文特征
成功握手有固定三步；失败则必卡在其中某一步，每种失败在Wireshark中都有明确报文痕迹：
- 第一次握手缺失（无SYN）：过滤 tcp.flags.syn == 1 and ip.src == [你的IP]，结果为空 → 说明应用层根本没发出连接请求。常见原因：终端命令输错IP/端口、防火墙拦截出站、本地路由不可达、或程序未真正调用connect()
- SYN发出但无SYN-ACK返回：能看到你的SYN包（Flags: 0x02），但后续几秒内没有来自目标IP+端口的SYN-ACK（Flags: 0x12）→ 大概率目标主机不在线、IP不可达、中间防火墙静默丢弃、或目标端口未监听。可配合ping验证ICMP通路，再用 tcpdump -i eth0 port 8080（Linux跳板机）交叉验证
- 收到RST响应而非SYN-ACK：你的SYN发过去，对方立刻回一个TCP RST（Flags: 0x04）→ 明确表示“我收到了，但拒绝连接”。典型场景：目标服务进程未启动、端口被占用但未监听、防火墙策略主动拒绝（而非丢弃）、或目标系统启用了TCP RST保护机制
- 收到SYN-ACK但未发ACK（第三次握手缺失）：能看到对方SYN-ACK，但你本机没发出对应ACK → 通常说明Windows协议栈已拒绝该连接，可能因本地端口耗尽（TIME_WAIT堆积）、SOCKET创建失败、或安全软件劫持拦截
结合关键字段缩小根因范围
单看SYN/SYN-ACK/RST还不够，几个细节字段能帮你跳过试错，直指配置或系统层问题：
- TTL值：SYN包发出时TTL=128（Windows默认），若抓到的SYN包TTL=64或63，说明中间经过了Linux网关或容器，可能路径不对
- 源端口异常：终端使用的源端口不在动态端口范围（49152–65535），比如是1023以下，可能是程序硬编码或权限问题导致绑定失败
- 窗口大小为0：SYN-ACK中win=0 → 对方TCP栈异常，无法分配接收缓冲区，多见于资源耗尽或内核故障
- 校验和错误（Checksum incorrect）：Wireshark标红提示 → 物理层干扰、网卡Offload功能（如TSO/LRO）开启导致伪校验和，需在Wireshark首选项→Protocols→TCP中勾选“Validate TCP checksums”并禁用网卡硬件校验和卸载
辅助验证手段不可少
Wireshark提供的是“发生了什么”，但有时需要外部信息佐证“为什么发生”：
- 在Windows上运行 netstat -ano | findstr :8080，确认目标端口是否真有进程监听
- 执行 Test-NetConnection 192.168.1.100 -Port 8080（PowerShell），它会整合ICMP、TCP握手、超时等结果，比单纯telnet更透明
- 检查Windows防火墙日志（WF.msc → 高级设置 → 监视 → 日志设置），确认是否有出站/入站规则实际阻断
- 若目标是本地服务，尝试用 127.0.0.1 替代 localhost 抓包——后者可能走IPv6或环回优化，绕过Wireshark捕获
