1. 场景描述:常见场景为在香港部署多台 VPS,通过云厂商或第三方负载均衡(LB)做前端流量分发,域名解析(A/AAAA/CNAME/ALIAS)指向负载均衡或某台 VPS。常见故障包括域名解析不生效、负载均衡健康检查失败、请求到达但后台无响应、SSL 证书错误、会话丢失等。
2. 步骤:a) 使用 dig 或 nslookup 查看解析记录:dig +short yourdomain.com @8.8.8.8;nslookup yourdomain.com ;b) 检查是否指向负载均衡 IP 或 CNAME 名称;c) 验证 TTL 是否过长(若修改记录需先把 TTL 调低到 60-300);d) 使用 whois 或 registrar 面板确认域名是否被锁定或 DNS 托管是否在预期的位置。
3. 误区与修复:a) 误区:将根域直接 CNAME 到 LB(大多 DNS 不允许)。修复:根域使用 A 记录指向 LB 的弹性 IP 或使用 ALIAS/ANAME(DNS 服务支持时);b) 误区:忽略负载均衡提供的域名检查要求(如必须使用 CNAME)。修复:按厂商说明设置记录;c) 误区:只在一个 DNS 节点改记录而忘记托管 DNS。修复:把域名的 NS 指向正确 DNS 服务并等待生效。
4. 步骤包括:a) 确认服务监听地址:在每台 VPS 上运行 ss -tulpn | grep :80,确保服务监听 0.0.0.0 或 LB 可访问的内网地址;b) 配置防火墙放通健康检查 IP/端口,若用 ufw:ufw allow proto tcp from
5. 操作示例:a) 若应用监听在 8080,但 LB 只支持转发到 80,可在 VPS 做端口转发:iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080;保存规则:iptables-save > /etc/iptables.rules;b) 使用 systemd 在启动时恢复规则,或在 /etc/rc.local 添加 iptables-restore;c) 若使用 firewalld,运行 firewall-cmd --permanent --add-port=8080/tcp 然后 firewall-cmd --reload;d) 确保 kernel net.ipv4.ip_forward=1(若做路由/NAT),通过 sysctl -w net.ipv4.ip_forward=1 临时生效并写入 /etc/sysctl.conf。
6. 示例与要点:a) Nginx 作为反向代理示例:在 server 中 proxy_pass http://backend_upstream; 配置 upstream backend_upstream { server 10.0.0.2:8080; server 10.0.0.3:8080; } 并设置 proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; b) HAProxy 示例:frontend http-in bind *:80 default_backend servers;backend servers balance roundrobin server s1 10.0.0.2:8080 check inter 2000 fall 3 rise 2;c) 如果应用依赖会话,启用粘滞(sticky)配置或让应用使用共享 session 存储(Redis、数据库);d) 如果 SSL 在负载均衡终止(TLS termination),确保后端接受来自 LB 的 X-Forwarded-Proto 头并生成正确的重定向。
7. 操作指南:a) 若证书部署在 LB 上,域名需指向 LB,证书安装后通过 openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 查看证书链;b) 若证书在后端,确认 LB 做 TCP 转发而非 TLS 终止,或配置 LB 为 Layer4;c) 常见错误为 SNI 不匹配,解决办法是正确配置 SNI(在 curl 中使用 --resolve 测试)或把多个域名加入 SAN;d) 证书自动续期(Let's Encrypt)场景要保证 renewing 服务可访问 80/443,或使用 DNS-01 校验并把 API 密钥布署到 DNS 提供商。
8. 排查方法:a) 将域名 TTL 临时降到 60 秒并等待原 TTL 到期后再修改记录;b) 使用多个公共 DNS 解析器核对:dig @8.8.8.8、@1.1.1.1、@223.5.5.5;c) 本地浏览器或系统可能缓存 DNS,Windows 下 ipconfig /flushdns,macOS 下 sudo killall -HUP mDNSResponder,Linux 下重启 nscd 或 systemd-resolved;d) 若 CDN 或 ISP 缓存问题,联系 CDN/ISP 支持并核对边缘节点解析情况。
9. 步骤:a) 在 LB 上查看访问日志和健康检查日志,确认健康检查的来源 IP、路径、返回码;b) 在 VPS 上查看应用日志(access/error)和 nginx/haproxy 日志;c) 抓包 tcpdump -i eth0 port 80 -w capture.pcap,在本地用 Wireshark 或 tshark 分析三次握手、RST、返回码、延迟等;d) 使用 curl -v --resolve yourdomain.com:443:IP https://yourdomain.com/healthz 直接模拟外部请求,看请求链路是否存在中断或重定向错误。
10. 建议:a) 在做 DNS/负载均衡变更前先在开发/测试环境复现并验证;b) 变更时先把部分后端从 LB 移出做灰度(Drain connections),确认无异常后再逐步加入或替换;c) 变更 DNS 时先把 TTL 调低,变更后观察 24-48 小时;d) 制定回滚脚本(恢复 DNS、移回后端节点、恢复iptables配置),并在变更窗口内保持团队随时可执行回滚。
11. 清单项:a) DNS 是否解析到期望 IP/CNAME;b) LB 是否健康检查通过,检查来源 IP/路径/端口;c) 后端服务是否监听正确 IP/端口;d) 防火墙、security group 是否放行来自 LB 的流量;e) SSL 是否在正确的组件上终止并且证书链完整;f) 日志/抓包是否有明显错误码或连接重置。
12. 问答:首先确认 DNS 生效(dig yourdomain +trace),检查本地是否缓存(flush dns);其次确认负载均衡的后端服务器配置是否仍含旧服务器,登录 LB 控制台查看后端列表并移除旧节点,检查 LB 的会话保持策略(sticky)是否导致老会话继续命中旧服务器;最后检查 CDN 或 DNS 提供商是否有边缘缓存并触发刷新。
13. 问答:先查看 LB 报告的失败原因(超时/4xx/5xx/连接重置);用 curl 模拟 LB 源 IP(--interface 或使用 --resolve 指定 IP)测试相同路径;检查防火墙是否限制了来自 LB 指定的健康检查 IP;确认服务监听地址不是 127.0.0.1 而是 0.0.0.0 或内网 IP;检查是否存在基于 Host header 的访问控制导致返回非 200。
14. 问答:操作建议包括在变更前提前把 TTL 降低到 60 秒并等待原 TTL 到期;变更后通过多 DNS 服务(8.8.8.8/1.1.1.1)验证;如果业务对切换敏感,可先把流量引导到 LB 并在 LB 上做流量分流做灰度;为避免影响,准备好回滚记录和脚本,并在变更时通知用户可能的短暂波动。