公共WiFi下EC2部署网站的HTTP请求被阻断问题排查

从你的描述和net-internals日志来看，这个问题核心是TCP连接无法建立（日志里的ERR_CONNECTION_TIMED_OUT和os_error=60），而非CORS配置或AWS安全组的问题——毕竟你在其他网络环境下能正常访问，说明安全组和CORS设置是有效的。下面是具体的排查和解决步骤：

1. 优先排查公共WiFi的端口封锁（最可能的原因） #

很多公共WiFi为了网络安全，会默认封锁80、443之外的非标准端口（你的后端用的是3001端口，属于这类）。这是公共网络的常见限制，和AWS配置无关。

验证方法 #

在公共WiFi环境下，用以下命令测试端口连通性：

# 测试TCP连接是否能建立
nc -zv 35.153.17.199 3001
# 或者用telnet
telnet 35.153.17.199 3001

如果返回连接超时或拒绝，就坐实了端口被封锁的问题。

解决方案 #

• 方案一：把后端服务迁移到标准端口：让Express监听80（HTTP）或443（HTTPS）端口（需要root权限，或者用setcap给Node进程授权）。
• 方案二：用Nginx做反向代理：在EC2上安装Nginx，监听80端口，将请求转发到3001端口。示例Nginx配置：

  server {
      listen 80;
      server_name your-domain.com;
  
      location / {
          proxy_pass http://localhost:3001;
          proxy_set_header Host $host;
          proxy_set_header X-Real-IP $remote_addr;
      }
  }
  

• 方案三：使用AWS弹性负载均衡（ELB）：创建一个ALB（应用负载均衡），将80端口的流量转发到EC2实例的3001端口，同时确保ALB的安全组允许公共访问。

2. 检查公共WiFi的DNS解析问题 #

部分公共WiFi的DNS服务器可能存在解析故障，导致你的域名无法正确指向EC2的IP。

验证方法 #

在公共WiFi下执行：

nslookup your-domain.com
# 或者
dig your-domain.com

看返回的IP是否是35.153.17.199。如果解析错误或超时，可以手动切换DNS服务器（比如谷歌的8.8.8.8或Cloudflare的1.1.1.1）再测试。

3. 排除AWS子网NACL的限制 #

虽然你的EC2安全组允许所有TCP流量，但子网的**网络ACL（NACL）**是另一个层级的防火墙，可能存在入站/出站规则限制3001端口。

排查步骤 #

• 登录AWS控制台，找到EC2实例所在的子网
• 查看子网的NACL规则：确保入站规则允许TCP 3001从0.0.0.0/0访问，同时出站规则允许TCP 3001的响应流量返回。

补充说明：关于「Provisional Headers are Shown」 #

这个提示是浏览器的正常表现，因为TCP连接根本没建立成功，浏览器无法从服务器获取响应头，所以只能显示临时的请求头——它是连接失败的结果，而非原因，不用针对这个提示本身排查。

另外，你的CORS配置看起来没问题，因为CORS是HTTP层面的校验，只有当TCP连接建立、HTTP请求发送后才会触发，而现在连TCP都没通，所以CORS不是问题所在。

内容的提问来源于stack exchange，提问作者cookersjs