高防IP接入后502错误排查：反向代理回源链路与配置

上周凌晨两点多被电话叫起来说业务站全站 502值班的 A 同学第一反应是重启应用重启完还是 502第二反应是回滚代码回滚完依旧 502。后来一查当晚正好是新接的高防 IP 完成解析生效的时间点。把回源配置里的端口从 80 改成 443三分钟恢复。这类事情我碰过不止一次它有个共同特征源站本身活得好好的一接高防 IP 就开始报 502一撤高防就好了。很多人第一反应是高防有问题其实大部分时候是高防和源站之间的那层约定没对齐。这篇东西就是把这条链路拆开讲透。网站接入高防IP后提示502错误本质上是因为高防 IP 承担了反向代理的角色链路从用户直连源站变成了用户→高防节点→源站中间多了一跳就多了一堆可能出问题的位置。502 这个状态码的含义是作为网关或代理的服务器从上游服务器收到了无效响应翻译成人话就是高防节点去敲源站的门要么敲不到要么敲到了但对方说了句它听不懂的话。内容适合三类人看正在给站点接高防、接完就报错急着救火的运维排查 CDN 回源、负载均衡回源问题的开发以及想弄明白为什么加了一层代理就出问题这个通用规律的技术同学。下面从链路拆解讲到逐层定位再到具体配置和踩坑记录尽量给到能直接抄的东西。1. 先搞清楚 502 到底是谁返回的1.1 一条链路上 502 可能出现的三个位置不做这一步区分后面所有排查都是瞎猜。浏览器上看到502 Bad Gateway这一行字可能是三个完全不同的角色吐出来的第一个位置是高防节点自己。高防节点收到用户请求后去回源连不上源站、或者源站返回了它认为非法的内容它就直接给用户回 502并且这个 502 是高防的错误页样式往往带一个特征头或者一个定制页面。第二个位置是源站前面的 Nginx 或其它反向代理。这种情况下请求已经完整到达源站了但 Nginx 后面挂的应用进程比如 PHP-FPM、后端的 Java 服务、上游的容器挂了或者超时了Nginx 回 502 给高防高防原样透传给用户。这种 502 跟你接不接高防没关系只是接上之后你才注意到。第三个位置是中间可能还夹着一层 CDN。有些架构是 用户→CDN→高防→源站那 502 的产地就更多了。区分方法很朴素看响应头里的Server字段和有没有特征头看错误页长什么样高防的错误页通常有统一的模板再对比一下直接访问源站 IP 时的行为。如果直连源站一切正常、只有走高防才 502那基本可以锁定在第一个位置也就是高防回源这一段。提示把高防的错误页和源站 Nginx 的错误页各截一张图存下来下次半夜被叫起来的时候先看图就能省掉十分钟。1.2 接入前正常、接入后报错这条线索的含金量这条线索非常值钱它直接排除掉一大半可能性。它说明源站的服务进程是活着的否则接入前也是 502源站的监听端口是通的否则接入前也访问不了源站的证书大概率是有效的否则接入前浏览器就报警了。问题几乎必然出在新增的这一跳和两次握手之间的约定上。按我的经验接入高防后 502 的概率排序大致是这样的回源端口/协议写错占四成源站把高防回源 IP 段挡了占两成半回源 Host 或 SNI 对不上占一成半证书信任链问题占一成超时和连接数占一成剩下是健康检查、WebSocket 没开、长连接配置之类的杂项。这个排序很重要它决定了你的排查顺序。很多人上来就去抓包、看 TLS 握手细节折腾两小时其实问题就是控制台里那个默认的 80 端口没改成 443。先查最傻的可能性再查最复杂的可能性这条原则能救很多时间。1.3 动手之前先做的三件保命事第一件把当前的解析记录完整记录下来包括 TTL 值。改解析之前先看一眼 TTL如果是 3600意味着回滚也要等一小时那就在改之前先把它调小到 60 或 300等生效再动。这个动作很多老手都会忘出事的时候想快都快不了。第二件灰度切换。别整站全量切先把一个不重要的子域名指到高防上试水跑一天没问题再切主站。子域名用test-之类的临时前缀验证完删掉。第三件在本地留一条直连源站的 hosts 通道把源站 IP 和域名写进本机 hosts任何时候都能绕过整个链路做对照实验。这条通道在你半夜脑子不清醒的时候价值连城。2. 回源失败的高频原因逐个拆解2.1 回源端口与协议不匹配四成问题都在这里高防 IP 的配置面板里回源协议和回源端口是两个必填项而且大部分产品默认是 HTTP 80。如果你的源站只开了 443比如强制 HTTPS 的站点或者源站的 80 端口被防火墙封了只留 443那高防就会拿着 80 端口去敲门一直敲不开最后给你一个 502。反过来也成立配置面板里选了回源协议 HTTPS但源站那个端口其实是明文的 HTTP高防会尝试做 TLS 握手源站回一堆乱码或者直接 RST高防判定为无效响应还是 502。这种情况的表现通常是连得很快几十毫秒就返回 502因为根本不存在超时等待。还有一个更隐蔽的变种协议和端口都对了但 TLS 版本对不上。有些源站为了安全把 TLS 1.0 和 1.1 关掉了只留 1.2 和 1.3而某些高防节点回源时默认用的 cipher suite 比较老握手直接失败。表现是回源耗时偏高因为要等握手超时日志里能看到 SSL handshake 相关的错误。排查这个非常快把回源协议和端口在控制台里改成和源站监听完全一致保存等一分钟生效重新访问。如果通了就是这个问题。别小看这个动作我见过不止一个团队为此排查了一整个通宵。2.2 源站把高防的回源 IP 段挡在了门外这是最阴的一个坑因为它的表现不是全站 502而是大部分时候正常、偶尔 502或者某些地区报错、某些地区正常。原因在于高防的回源出口不是固定单 IP而是一个 IP 段且不同可用区的节点用的是不同的出口段。你只在源站防火墙里加了其中几个 IP就会有一部分节点能通、一部分不能通表现出来就是随机性的 502。常见被忽略的地方有一串云主机的安全组、系统层面的 iptables 或 firewalld、Nginx 里配的allow/deny、应用层的 WAF 规则、防爆破类的工具把高频访问的高防回源 IP 当成了攻击源自动封禁、还有面板类工具的 IP 黑名单。任何一层没放行都会断。正确的做法是把高防厂商公布的回源 IP 段全部放行而且要用脚本定期同步。因为这些段是会变的厂商新增节点时不会挨个通知你。手工维护名单这件事在半年后一定会出问题。注意放行策略要写成只放行回源段 全局默认拒绝而不是全局允许 黑名单。前者即使漏了某几个 IP表现是不通你立刻能发现后者漏了不会有任何提示直到某天被人绕过高防直接打源站。2.3 回源 Host 与 SNI 对不上一个 404 引发的 502源站的 Nginx 是靠server_name分流站点的。如果高防回源时带的 Host 头是高防 IP 或者一个默认值请求就会落到源站 Nginx 的default_server上。如果你的默认站点配置里挂了一个并不存在的 upstream或者默认站点被配置成return 502就会直接吐 502。多站点服务器上这个问题尤其容易撞。同一台机器上跑了五六个站某个站的配置里default_server标错了位置所有没匹配上 Host 的请求都进了它然后它的 upstream 早就下线了。SNI 是同一个问题的 HTTPS 版本。源站如果配置了多个证书靠 SNI 区分你回源时不带 SNI 或者带错了 SNINginx 会给你返回它认为的默认证书客户端高防校验域名不匹配判定失败。处理办法有两个层面一是在高防的域名配置里明确填写回源 Host填成源站 Nginx 里真实存在的server_name二是在源站 Nginx 里给默认站点加一个兜底规则比如return 444直接断连或者return 403这样即使 Host 没对上也不会伪装成 502 让你误判成后端故障。2.4 HTTPS 回源时的证书信任链问题回源协议选 HTTPS 时高防节点实际上是作为一个客户端去校验源站证书的。校验的内容包括证书是否在有效期内、证书的 CN/SAN 是否包含你回源使用的域名、证书链是否完整中间证书有没有装、证书是否由受信任的 CA 签发。源站自签证书是必挂的这个不用多说。更容易踩的是证书链不完整有些证书文件只包含站点证书本身没包含中间证书浏览器因为会自己去补全所以看不出问题但高防节点这种严格的客户端就直接握手失败。表现特征是浏览器直连源站正常接高防后 502且回源耗时略长。确认方法是用openssl s_client对着源站的 443 端口跑一遍看输出的证书链里是不是只有一张证书。完整的链应该至少有两张。解决方式有三种按推荐程度排序把完整证书链含中间证书重新部署到源站把证书上传到高防平台由平台托管实在不行在回源配置里关掉证书校验这个选项要看平台是否提供风险是回源流量可能被中间人劫持内网环境才建议。2.5 超时时间与连接数被掐断的慢请求高防节点的回源超时默认值通常不大十秒到十五秒是常见配置。如果你源站有个接口要跑二十秒导出报表、批量查询、复杂的图片处理直连的时候用户浏览器愿意等走高防的时候高防不等了主动断开并返回 502 给用户。这种 502 的特征是小接口都正常只有特定的几个慢接口报错而且报错的时间点很规律。另一类是连接数打满。高防回源的并发能力通常远大于单个源站的处理能力等于是把你源站的入口流量瞬间放大了一个量级因为高防本身会做连接复用且清洗后的流量依然是真实的。源站的worker_connections、操作系统的somaxconn、net.core.somaxconn、应用的线程池大小任何一个成为瓶颈表现就是间歇性 502且高峰期严重。还有一类很隐蔽高防回源默认走短连接每个请求都重新握手源站上积累大量 TIME_WAIT端口耗尽。这个问题在 QPS 上到几千的时候会突然爆发前一周都好好的。2.6 健康检查误判导致的整站摘除高防平台一般会配置健康检查定期探测源站的某个路径返回 2xx 才认为源站健康。如果健康检查的路径配的是一个需要登录才能访问的页面返回 302 或 401或者配的是根路径而根路径返回了 403探测就会失败平台认为源站全部故障所有请求直接回 502一个都不回源。这种故障的表现很典型改完配置后头几分钟一切正常过了几分钟突然全站 502而且是一刀切式的全挂日志里没有任何回源记录。很多人这时候会去查证书、查端口其实控制台里健康检查那一栏红着呢。正确的健康检查路径要满足几个条件源站上真实存在的静态资源、返回 200、不消耗数据库连接、不触发任何业务逻辑。通常的做法是在源站专门放一个/health.html或者由 Nginx 直接return 200 ok;处理的路径。3. 从现象收敛到根因的四步定位法3.1 第一步确认解析真的完全生效了听起来很傻但确实有人在这里翻车。DNS 的 CNAME 链可能有好几层你改了第一层后面的还没更新本地 DNS 有缓存你测通的其实是缓存不同运营商递归 DNS 的刷新速度不一样你这边通了用户那边还没通。验证方式是拿多个第三方 DNS 检测工具查看全国主要节点返回的是不是都已经指向高防的 CNAME。同时用dig加上trace参数看看完整的解析链。另外注意 TTL 生效需要时间改完立刻测是不准的。这一步还有个变种域名同时配了 A 记录和 CNAME或者主域名和 www 子域的解析没有同步改。用户访问 www 走高防正常访问裸域走源站暴露看起来时好时坏其实是两个域名的解析状态不一致。3.2 第二步直连源站做对照实验用curl --resolve可以在不改 hosts 的情况下强行把域名指到源站 IP这是排查这类问题最好用的手法# 强制把域名解析到源站 IP走 HTTPS看完整响应 curl -v -k --resolve www.example.com:443:203.0.113.10 https://www.example.com/ # 只测回源 TCP 端口通不通不涉及 TLS curl -v telnet://203.0.113.10:443 --connect-timeout 5 # 指定 Host 头访问源站验证 Nginx 分流是否正常 curl -v -H Host: www.example.com http://203.0.113.10/三条命令分别回答三个问题源站的 443 端口在应用层是否正常响应、TCP 层是否可达、Host 分流是否命中正确的站点。如果三条都正常说明源站没问题问题在高防侧或者高防到源站的网络路径上。如果第二条就失败了说明是端口或防火墙问题跟高防没关系。3.3 第三步看高防控制台的回源日志和错误码高防平台一般会在访问日志里给出回源的详细结果包括回源的源 IP、耗时、返回码、错误原因。错误原因那一栏是最有价值的信息常见的有连接超时证书校验失败回源响应异常连接被拒绝。看到连接被拒绝就往端口和白名单方向查看到证书校验失败就往证书链方向查看到响应超时就往慢接口和超时配置查。有些平台还会给一个更细的回源耗时分解DNS 耗时、TCP 握手耗时、TLS 握手耗时、首字节耗时。TLS 握手耗时特别长大致就是握手失败在重试TCP 握手耗时长为零但没后续多半是被对端 RST 了。3.4 第四步源站侧抓包确认请求到底有没有到这一步是分水岭。在源站上抓包看高防节点的 IP 有没有真的把 SYN 包发过来# 抓 443 端口的所有入向流量只看前 100 个包 tcpdump -i any -nn -c 100 tcp port 443 and tcp[tcpflags] tcp-syn ! 0 # 抓某个具体的高防回源 IP tcpdump -i any -nn host 198.51.100.23 and port 443三种结果对应三个完全不同的故障域抓不到任何包说明请求根本没到源站问题在中间网络、安全组、或者源站机器上的 iptables 把包丢了。这时候别在源站的应用配置上浪费时间。抓到了 SYN但源站回了 RST说明包到了但端口没在监听或者被 REJECT 规则拦了。查ss -lntp看端口状态。抓到了完整的 TCP 握手和请求源站也正常回了包但高防还是判定失败那问题就在应用层协议上——Host 不对、证书不对、响应内容不符合高防的校验规则、或者是超时。3.5 现象与原因对照表现象特征最可能的原因优先验证方式全站立即 502几十毫秒返回回源端口/协议写错或健康检查全挂查控制台回源配置与健康检查状态部分请求 502随机分布回源 IP 段未全量放行部分节点不通源站抓包看失败请求的源 IP只有 HTTPS 站点 502证书链不完整或 SNI 不匹配openssl s_client 检查证书链只有慢接口 502回源超时设置过短对比接口耗时与超时阈值高峰期大面积 502低峰正常源站连接数或端口耗尽看 ss 的 TIME_WAIT 数量和连接数接入几分钟后全挂日志无回源健康检查被误判节点全摘控制台看源站状态标记静态资源正常动态接口 502应用层故障与高防无关直连源站复现页面能开但样式全丢、跳转异常Host 头没传对触发重定向看浏览器网络面板的跳转地址4. 落地配置把回源这条链路彻底钉死4.1 源站侧回源 IP 段放行与自动同步先把高防厂商公布的回源 IP 段整理成一份列表用脚本同步到 iptables。下面是通用写法实际使用时把 CIDR 换成你所用平台公布的段#!/bin/bash # sync_origin_allow.sh # 用途把高防回源 IP 段同步到专用链避免影响其它规则 CHAINORIGIN_ALLOW IPS( 198.51.100.0/24 203.0.113.0/24 192.0.2.0/25 ) # 链不存在则创建存在则清空重建幂等 iptables -N $CHAIN 2/dev/null iptables -F $CHAIN for cidr in ${IPS[]}; do iptables -A $CHAIN -s $cidr -j ACCEPT done # 拿到真实客户端 IP 后其余流量才允许访问 80/443 # 这里是示意先放行回源段再拒绝其它直连防止绕过 iptables -A $CHAIN -j RETURN iptables -C INPUT -j $CHAIN 2/dev/null || iptables -I INPUT 1 -j $CHAIN echo synced $(date %F %T) - ${#IPS[]} cidrs配上 crontab 每天跑一次加个失败告警。同时把这份列表同步一份到云平台的安全组两层都要覆盖。别只做系统层的 iptables因为云安全组是在 iptables 之前生效的只改一层等于没改。提示链名用自定义的ORIGIN_ALLOW而不是直接往 INPUT 里堆规则好处是回滚时一条iptables -F ORIGIN_ALLOW就干净了不会把自己其它的规则也清掉。这个习惯救过我一次。4.2 Nginx 侧兜底站点与真实 IP 还原源站 Nginx 要处理三件事接住高防带来的 Host、把真实客户端 IP 从X-Forwarded-For里还原出来否则日志里全是高防 IP风控和限流全废、给不匹配的请求一个明确的拒绝而不是伪装成 502。# 真实 IP 还原信任高防回源段从其携带的头里取真实客户端 IP set_real_ip_from 198.51.100.0/24; set_real_ip_from 203.0.113.0/24; real_ip_header X-Forwarded-For; real_ip_recursive on; # 兜底站点放在所有业务 server 之前接住所有 Host 不匹配的请求 server { listen 80 default_server; listen 443 ssl default_server; server_name _; # 明确拒绝而不是让请求落到某个错误配置的站点上 return 444; } server { listen 443 ssl; server_name www.example.com; # 证书链必须是完整链含中间证书 ssl_certificate /etc/nginx/cert/fullchain.pem; ssl_certificate_key /etc/nginx/cert/privkey.pem; ssl_protocols TLSv1.2 TLSv1.3; # 回源超时与高防侧的超时配置对齐 proxy_connect_timeout 10s; proxy_send_timeout 60s; proxy_read_timeout 60s; # 回源长连接减少 TIME_WAIT 堆积 upstream backend_app { server 127.0.0.1:8080; keepalive 64; } location / { proxy_http_version 1.1; proxy_set_header Connection ; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_pass http://backend_app; } # 健康检查专用路径纯 Nginx 处理不落业务 location /health.html { access_log off; default_type text/plain; return 200 ok; } }几个关键点展开说一下。real_ip_recursive on这个参数在多层代理时很关键它会从右往左剥掉可信代理的 IP直到找到第一个不可信的地址那才是真实客户端。如果你的回源段没配全剥不干净日志里就会混着高防 IP 和真实 IP做风控的时候会误封一大片。return 444是 Nginx 特有的写法直接关闭连接不回任何响应。用它做兜底的原因是不给攻击者任何信息也不占用后端资源比return 502好得多——后者会让你在排查时误以为后端挂了。4.3 超时与连接数给出可用的计算口径超时不能拍脑袋填。比较靠谱的口径是拿源站近 30 天该接口的 P99 响应时间乘以 2再向上取整到 5 的倍数。比如导出报表接口 P99 是 22 秒那超时就设 45 到 50 秒。设太大没有意义只会让故障时的等待更痛苦设太小就是自己造 502。连接数要算三笔账。第一笔是 Nginx 的worker_connections公式是worker_processes * worker_connections得到总的并发上限但这个上限里每个请求占两条客户端连接 回源连接所以要除以 2。第二笔是操作系统的net.core.somaxconn和net.ipv4.tcp_max_syn_backlog这两个决定 accept 队列能排多长高并发下建议都调到 65535。第三笔是应用进程自己的线程池或连接池它往往是真正的瓶颈且最难扩容。回收 TIME_WAIT 的问题最有效的办法不是调内核参数而是让 Nginx 到上游走长连接也就是上面配置里的keepaliveproxy_http_version 1.1 清空Connection头这三件套。改完之后 TIME_WAIT 的数量通常会下降一个数量级。4.4 回源方案的关键参数对照参数直连源站时的典型值走高防后的建议值说明回源协议无与源站监听一致HTTPS 站点必选 HTTPS写错的概率最高回源端口无80 或 443 或自定义必须与ss -lntp一致建议先ss确认再填回源 Host无源站 Nginx 中真实存在的server_name多站点服务器必查连接超时无5 到 10 秒超过说明网络异常读超时无P99 × 2取 5 的倍数慢接口单独评估健康检查路径无独立静态路径返回 200不要用需要登录的页面健康检查间隔无5 到 10 秒连续 2 到 3 次失败才判定避免抖动导致全摘5. 常见问题速查与踩坑实录5.1 速查表十种 502 与对应处置序号现象根因处置动作1改完配置立刻全站 502回源端口填成默认 80源站只开 443改回源端口与协议保存生效2部分运营商 502解析未全国生效或回源段部分未放行多节点查解析补全放行段3只有 www 502裸域正常两个域名解析状态不一致统一改为 CNAME 指向高防4HTTPS 站点 502HTTP 正常证书链缺中间证书用 openssl 验链补全证书5静态页正常接口 502接口耗时超回源读超时调大超时或异步化接口6接入几分钟后全挂健康检查路径返回 403/302换独立静态健康路径7高峰期大面积 502源站连接数或端口耗尽开长连接调大 backlog8后台登录后跳转到源站 IP应用生成绝对 URL 未适配改配置或加响应头替换规则9WebSocket 连接立即断开高防未开启 WebSocket 支持控制台开启并配长连接超时10工单说源站正常但仍 502高防节点侧缓存了错误的回源结果刷新缓存或联系平台重置节点5.2 只有踩过才知道的几个细节跳转地址暴露源站。应用里如果用绝对路径生成重定向比如登录成功后Location: http://203.0.113.10/admin那用户虽然是从高防进来的浏览器会直接跳到源站 IP 上去。表现是页面能开点一下就 502 或打不开。改法是让应用从X-Forwarded-Proto和 Host 头动态生成 URL而不是写死。排查时打开浏览器的网络面板看那几个 301/302 的 Location 指向哪里一眼就能看出来。证书到期时间不同步。源站的证书换了新的高防平台上还留着旧的那份或者反过来。到期前一个月一切正常到期当天全站 502。这个坑的解法很简单但需要有人做把两边的证书到期日记进日历提前两周做更换演练并且更换后立刻用openssl s_client -connect 域名:443 -servername 域名验证两边的指纹是否一致。回源段和 CDN 段混在一起维护。有些架构里高防是给源站做防护的前面还挂着 CDN等于有两套回源 IP 段要放行。只加了其中一套表现是用某些地区访问正常某些地区 502。维护的时候把两套段放同一个配置文件里按来源分开写注释别混着丢进一个大数组。健康检查把源站打成故障。健康检查间隔设成 1 秒、源站是个小配置的机器检查请求本身就把资源占满了然后业务请求超时然后被判死。检查间隔至少要 5 秒以上路径必须是最轻量的静态返回。域名验证和泛域名证书的边界。用泛域名证书的时候如果回源 Host 填的是一个二级甚至三级子域证书的 SAN 里可能不包含它校验就失败了。这种情况下要么给回源 Host 单独配一张证书要么把回源 Host 改成泛域名能覆盖的形式。控制台的回源不校验证书选项不是万能药。它能让你快速恢复业务但它关闭的是整条链路的服务端身份验证等于回源流量可以被任意中间设备伪造。应急可以开事后必须补回完整的证书配置并关掉这个开关。我见过开了两年没人管的这种配置在安全审计里是要被点名的。5.3 一套十分钟的应急排查顺序半夜被叫起来脑子不清楚的时候按这个顺序走不用思考机械执行就行先看高防控制台的源站健康状态红的就先查健康检查路径。绿色的往下走。再用本地 hosts 直连源站能开说明源站活着。然后在高防的域名配置里核对回源协议和端口与源站ss -lntp的输出逐字比对。接着用curl -v走高防访问一次看响应头里的 Server 和错误页特征判断 502 是高防吐的还是源站吐的。最后如果还是不通上源站tcpdump看有没有 SYN 包进来把故障域切成网络/白名单和应用/证书两半剩下的就好办了。这套顺序的价值在于它把六种可能性按出现概率从高到低排了一遍平均能在十分钟内命中。而漫无目的地查证书、查内核参数、查应用日志很可能两个小时还在原地。我个人在这方面最大的体会是接入任何一层代理本质上是给链路增加了一个约定。端口是约定Host 是约定证书是约定超时是约定健康检查是约定。所有的 502 几乎都能归结为某一项约定两边理解不一致。所以下次再遇到别急着怀疑高防有问题先坐下来把约定清单拉一遍一项一项对。对完之后通常你会发现问题所在而且往往简单得让你有点不好意思。