生产环境React应用首次加载正常刷新返回429错误的问题求助

从你提供的代码逻辑可以确定：429状态码不可能由你当前的Express应用返回。你贴出的server.js里没有任何实现429响应的逻辑，Express默认也不会主动生成该状态码，这个报错百分百来自请求链路的上游层——也就是Nginx或者EC2关联的云侧防护组件。

第一步：定位429的实际返回源 #

• 在EC2服务器本地直连Node端口验证：
  执行命令 curl -I http://127.0.0.1:你的Node服务端口/favicon.ico、curl -I http://127.0.0.1:你的Node服务端口/manifest.json，如果返回状态码为200，说明Node应用完全没有问题，后续排查全部聚焦Nginx层。
• 在服务器本地模拟外部域名访问Nginx端口：
  连续快速执行10次 curl -H "Host: 你的生产域名" -I http://127.0.0.1/favicon.ico，观察何时返回429，即可确认限流规则在Nginx上生效。

常见触发原因与修复方案 #

1. Nginx默认限流规则误触发 #

很多Nginx一键部署脚本、默认站点模板会默认开启ngx_http_limit_req_module限流配置，典型阈值为单IP每秒仅允许1-2个请求，burst溢出值仅为2。
你刷新页面时，浏览器会在1秒内并发发起favicon、manifest、入口JS、CSS、业务接口等5-10个请求，很容易超过阈值；首次访问时因为之前没有密集请求，限流冷却窗口已过，所以加载正常，连续刷新时冷却时间未到，就会被限流规则拦截返回429。
修复方式：

• 打开Nginx站点配置文件，搜索limit_req、limit_req_zone相关配置项，要么删除所有限流配置，要么调高阈值（比如设置单IP每秒允许20个请求，burst溢出值设为30）
• 配置修改完成后先执行nginx -t验证语法，再执行systemctl reload nginx让配置生效。

2. 静态资源全量反代到Node导致请求堆积 #

你目前的部署逻辑是所有请求全部转发到Node应用处理，包括favicon、manifest、构建后的静态JS/CSS文件。这类不需要服务端逻辑的静态资源全量走反代，既浪费Node的连接池资源，也容易因为短时间内请求堆积触发上游连接保护，返回限流类错误。
修复方式：在Nginx配置中做静态资源分流，静态文件直接由Nginx读取返回，不需要转发给Node：

# 替换成服务器上React构建产物的实际存放路径
root /your/app/full/path/public;
# 静态资源配置：直接由Nginx返回，加长期缓存减少重复请求
location ~* \.(ico|json|js|css|png|jpg|woff2?)$ {
    expires 30d;
    add_header Cache-Control "public, immutable";
}
# 仅动态接口请求反代到Node应用
location /api {
    proxy_pass http://127.0.0.1:你的Node服务端口;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
}
# 前端路由兜底：刷新非根路径时直接返回index.html，不做重定向
location / {
    try_files $uri $uri/ /index.html;
}

3. Express层重定向逻辑放大请求量 #

你当前Express配置中有一行兜底重定向逻辑：app.get("*", (_, res) => res.redirect("/"))，这个逻辑会把所有匹配不到静态文件、匹配不到路由的请求全部302重定向到根路径。
当用户刷新React路由内的非根路径（比如/about）时，浏览器会先请求/about，收到重定向后再重新发起整套静态资源请求，短时间内请求量直接翻倍，很容易触发上游的限流阈值。
修复方式：删除Express里的重定向兜底逻辑，配合Nginx的try_files配置实现前端路由兜底，避免额外的重定向请求。

补充配置修正 #

你当前的CORS配置仅允许了本地开发端口的源，生产环境的域名完全不在允许列表中，虽然这个问题不会直接导致429，但后续发起业务接口请求时会触发跨域报错，记得把生产域名（比如https://你的正式域名）加入allowedOrigins数组。

内容的提问来源于stack exchange，提问作者Ezequiel S. Sandoval