企业官网建设流程全解析

上周凌晨两点多被电话叫起来，说业务站全站 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 或者带错了 SNI，Nginx 会给你返回它认为的默认证书，客户端（高防）校验域名不匹配，判定失败。

处理办法有两个层面：一是在高防的域名配置里明确填写"回源 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 现象与原因对照表

4. 落地配置：把回源这条链路彻底钉死

4.1 源站侧：回源 IP 段放行与自动同步

先把高防厂商公布的回源 IP 段整理成一份列表，用脚本同步到 iptables。下面是通用写法，实际使用时把 CIDR 换成你所用平台公布的段：

#!/bin/bash # sync_origin_allow.sh # 用途：把高防回源 IP 段同步到专用链，避免影响其它规则 CHAIN="ORIGIN_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 到上游走长连接（也就是上面配置里的keepalive+proxy_http_version 1.1+ 清空Connection头这三件套）。改完之后 TIME_WAIT 的数量通常会下降一个数量级。

4.4 回源方案的关键参数对照

5. 常见问题速查与踩坑实录

5.1 速查表：十种 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 几乎都能归结为"某一项约定，两边理解不一致"。所以下次再遇到，别急着怀疑高防有问题，先坐下来把约定清单拉一遍，一项一项对。对完之后，通常你会发现问题所在，而且往往简单得让你有点不好意思。