这次 Java 网盘项目部署中，AWS EC2 连接不稳定并不是单一问题，而是「代理 DNS 配置」「校园网网络限制」和「TUN 流量转发模式」三者叠加后的结果。
把现象拆开之后，问题链路会清晰很多。
1. 初始报错：DNS 污染导致连接目标错误#
使用 Clash 代理时，出现该报错的本质是DNS 解析被篡改：
- Clash 默认 DNS 转发规则没有针对 AWS 域名（
*.amazonaws.com）做专门配置，解析请求被代理劫持后返回了虚假 IP，而不是 EC2 的真实公网 IP。 - SSH 客户端基于错误解析结果发起连接，目标主机并不是 AWS EC2 实例，因此被远端主动关闭，触发
Connection closed by remote host。 - 这种情况下，即使反复检查 EC2 安全组、入站规则和密钥权限，也无法解决问题，因为连接目标一开始就错了。
所以第一层问题不是 SSH，也不是 EC2 配置，而是 DNS。
2. 关闭 Clash 后无法 ping 通：校园网境外访问限制#
关闭 Clash 代理后，出现「无法 ping 通 EC2」的现象，核心是校园网防火墙的访问控制：
- 校园网可能会限制境外 IP 的直接访问，尤其是云服务厂商地址。
ping依赖 ICMP，SSH 依赖 TCP 22 端口，这两类流量都有可能被校园网出口策略拦截。- 无代理时，本地流量直接从校园网出口发送，不经过任何转发机制，自然无法绕过这些限制。
所以第二层问题是：关闭代理后 DNS 可能正常了，但网络路径不通。
3. 关闭 TUN 模式后秒连：规避流量转发异常#
开启 Clash 的 TUN 模式（虚拟网卡）时连接失败，关闭后秒连，本质是TUN 模式的流量转发机制与 SSH 协议不兼容：
- TUN 模式会创建虚拟网卡，接管系统所有网络流量。由于 WSL 2 共享 Windows 网络栈，WSL 的流量也会被纳入这条链路。
- 流量需要经过「虚拟网卡 → 代理节点」的额外转发，相比应用层代理多了一层干预。
- 这个过程中可能出现 MTU 不匹配，导致 SSH 数据包分片异常；也可能出现协议识别或转发规则误判，最终表现为连接重置。
关闭 TUN 模式后，Clash 只通过应用层规则转发流量。基于已配置好的 AWS 域名或 22 端口规则，流量可以从系统原生网络栈转发到代理节点，既保留了代理绕过校园网限制的能力，又减少了虚拟网卡带来的不确定性，因此实现秒连。
总结#
整个问题的核心逻辑链是：
Clash DNS 配置不当 → DNS 污染 → SSH 连接错误目标 → 关闭 Clash 后校园网阻断境外流量 → 关闭 TUN 模式后应用层代理正常转发 → 连接恢复
本质上，这是代理配置、网络环境和协议转发机制三者的适配问题。解决方向不是盲目重装或反复改安全组，而是：
- 修正 Clash 的 DNS 规则，避免 AWS 域名被污染；
- 保留必要代理，绕过校园网境外访问限制；
- 关闭不必要的 TUN 模式，减少 SSH 流量转发异常。