网关配置错误有哪些典型表现？

你有没有遇到过这种情况：网站明明部署好了，本地测试也正常，但一上线别人就是打不开？或者接口请求总是超时，前端调用后端服务像在撞墙？很多时候，问题就出在网关配置上。

访问页面直接404或403

最常见的表现就是用户访问网址，结果返回404 Not Found。看着路径没错，文件也上传了，但就是找不到。这往往是因为网关没把请求正确转发到后端服务。比如你在Nginx里配了个location块，但路径写错了：

location /api/ {
    proxy_pass http://localhost:8080/service/;
}

这里如果少了个斜杠，或者前后端路径不匹配，API请求就会被丢进黑洞。更烦人的是403 Forbidden，权限没设对，网关直接拒之门外，连错在哪都看不出。

静态资源加载失败，页面“裸奔”

网页打开，样式没了，图片出不来，按钮变文字，活脱脱一个“原始页面”。这通常是网关没正确处理静态资源路径。比如你把React打包后的文件放在/static下，但网关没配置静态目录：

location /static/ {
    alias /var/www/myapp/static/;
}

漏了这一段，CSS和JS全404，用户看到的就是个没化妆的前台小姐姐。

HTTPS跳转失败，安全锁变红叉

你想搞个正规站点，上了SSL证书，结果访问https还是跳回http，甚至直接连接失败。这是因为网关没监听443端口，或者rewrite规则写错了。常见于云服务器的负载均衡配置，后台看着证书已绑定，但前端死活不走加密通道。

跨域请求被拦，前端干瞪眼

前端同学最头疼的CORS问题，很多时候不是他们代码写得不对，而是网关没放行。比如你前端跑在localhost:3000，后端在api.example.com，网关要是没加响应头：

add_header Access-Control-Allow-Origin *;
add_header Access-Control-Allow-Methods 'GET, POST, OPTIONS';
add_header Access-Control-Allow-Headers 'DNT,X-Mx-ReqToken,Keep-Alive,User-Agent';

那OPTIONS预检请求直接被掐断，POST请求发不出去，界面按钮点了没反应，查半天才发现是网关在“背锅”。

负载均衡失效，一台机器累死

你搭了两台后端服务器想分摊压力，结果监控一看，一台CPU飙到90%，另一台闲得发慌。问题可能出在网关的upstream配置上。比如Nginx里写错了权重，或者健康检查没开，挂掉的节点还在列表里，活着的反而接不到请求。

upstream backend {
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
    # 缺少健康检查或权重分配
}

这种问题平时不显山露水，一到流量高峰就崩。

重定向循环，浏览器直接报错

访问网站，浏览器突然跳出“该网页无法正常运作”，提示重定向次数过多。这通常是网关在http和https之间来回跳，比如做了https重定向，但后端又返回http地址，网关再转，形成死循环。调试时可以用curl看跳转链，很快就能定位是不是网关配置惹的祸。

网关就像网站的大门保安，配置错了，不该进的进不来，该放行的被拦下。别等出了问题才翻文档，上线前多检查几遍转发规则、路径映射和安全头，能省下大把排查时间。