嵌入式开发者外链优化：3个被忽视的权重关键点

　　前年冬天，凌晨三点二十，机房空调啸叫得像台报废的伺服电机——我蹲在UPS柜子后面拧固态继电器螺丝时，监控屏右下角弹出第三条告警：外链域名解析失败。不是超时，是直接 NXDOMAIN。我第一反应是 DNS 劫持，抄起笔记本连上机柜侧边网口抓包，结果发现连 upstream 的 8.8.8.8 都 ping 不通。可我们用的是本地 CoreDNS 做递归，主配置里根本没写 8.8.8.8。这不对劲。

　　我原以为是上游 DNS 污染，结果翻 CoreDNS 日志，发现它压根没往外发请求。日志里全是 timestamp 和 query ID，后面跟着一串“refused”。Refused？不是 timeout，不是 nxdomain，是 refused。我手抖着 Ctrl+F “refused”，结果搜出四百一十七条——全集中在同一个上游 IP：192.168.4.35。那个 IP 是隔壁嵌入式组的老王部署的 DNS 缓存代理，就跑在一台刷了 OpenWrt 的 AR3200G 上，没开日志轮转，也没加 ACL。老王上周说“就透个 DNS，又不走业务流量，图省事”。

　　我拨他电话，他那边背景音是孩子哭，喊了两声“等会儿”，接着喂了三秒才接。我说：“你那台路由器的 dnsmasq 进程是不是把 TTL 设成零了？”他顿了五秒：“啊？TTL？我改过 hosts……” 我挂了。重新看 log，果然。所有外链域名查询，他那台机器都回了个 TTL=0 的 SOA，CoreDNS 一看，立刻丢进黑洞——不是缓存失效，是直接拒绝响应。TTL=0 在 RFC 1035 里明写着“禁止用于响应”，但 dnsmasq 就是吃了，还吃了两年。我们组用它做固件下载镜像源的 HTTP 重定向外链，一共十七个，全挂了。

　　窗外雨刮器似的敲打窗框，值班室桌上那桶红烧牛肉面汤早凉了，浮着层白油。我盯着屏幕上 curl -v 的输出：Connection refused。不是 Connection timed out，是 refused。这个细节我盯了四十来分钟，直到手指甲掐进掌心。我调出 git blame，看到去年六月老王提交的 config：dns-hosts = /etc/dnsmasq.hosts，而那份 hosts 里，每行末尾都多了一个空格，后面还带个 tab。没人动过，也没人 review。编译固件时，脚本读 hosts 文件会截断 tab 后的内容，但 dnsmasq 启动后解析这一行时——会把它当注释吞掉，然后顺手把整条记录的 TTL 强制设为 0。

　　老板在运维大群发了个截图，上面是某客户工单系统里跳出来的报错：“无法加载 SDK 文档（外链）”，底下附了一张手机相册照片，拍得歪斜，字都糊了。他@我说：“李工，这文档链接是谁管？是不是又 CDN 挂了？” 我回：“不是 CDN，是内网 DNS 把自己人拒了。” 他隔了十二分钟回了个问号。我没再碰手机。

　　后来查证，其实不止 DNS。第二处是证书信任链断裂：我们所有外链 URL 全用 http:// 而非 https://，因为某些嵌入式模块压根不支持 TLS 握手校验；但偏偏 nginx 反向代理那层配了 proxy_ssl_verify on，结果一碰带证书的上游服务，整个链路就僵在 ssl handshake failed ——不是证书过期，是它连 SNI 都没发出去，就被 proxy_pass 判为无效连接。我们之前一直以为是“模块兼容性问题”，其实是 proxy_ssl_verify on 在裸 HTTP 场景下不抛错、只静默失败。这个判断，我笃定是在凌晨四点十七分——那时候老王终于连上 SSH，把那台 AR3200G 的 dnsmasq 改回 default-ttl=60，但文档页还是白屏。我切到 nginx error log，看到第三行：“SSL_do_handshake() failed (SSL: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure)”，后面还跟一句：“while connecting to upstream”。我就知道，不是 DNS 的事了。

　　还有第三处：所有外链域名在设备端缓存有效期被硬编码进 Bootloader 里，不是 HTTP header 的 Cache-Control，是 flash 里一段 32 字节 struct，每次开机 memcpy 进内存。上次升级 Bootloader 时，小张用 Python 脚本自动生成这段数据，但他的脚本读取域名列表是从一个未版本化的 Excel 里扒的，Excel 最后两行是空的，脚本没 trim，于是生成的 struct 里第 16 个字段填的是 \\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00 ——整段乱码。设备一开机，就拿着这串乱码去连 DNS，而 CoreDNS 解析失败后返回 REFUSED，设备端解析库没做错误分支，直接卡死在 getaddrinfo 里，十秒超时后重试，重试三次后干脆关掉网络模块。所以故障期间，有设备连 WiFi 都连不上。小张那天请了婚假，婚礼录像发群里，背景音乐是《今天你要嫁给我》，我看着视频里他穿西装敬酒，手里的酒杯晃得很稳。

　　说到婚假，想起去年搬家。租的公寓楼电梯按键全是黏的，我拖着 32 寸显示器箱子蹭过七楼拐角，箱子底磕在消防栓上，屏幕裂了条细缝，但显示正常。修？不修。用了三个月，直到某个周五晚上，同一位置突然黑屏——原来裂缝早爬进了背光膜里，潮湿一胀，整片就短路了。这事跟我现在盯的外链优化一个德行：表象是断，实则是裂痕长了太久，谁路过都绕着走，没人掰开看。

文章配图，仅供参考

　　我到现在也没想明白，为什么 CoreDNS 对 REFUSED 不做重试、不记到 fallback 链路里。RFC 写了要 fallback，它就是不 fallback。也许它觉得 REFUSED 就是“明确拒绝”，不是“暂时不行”。可设备哪管这个。设备只认 errno，只信 timeout，只懂 reset。

　　明天先把 nginx 的 proxy_ssl_verify 改成 off。不改其他。先动这一个。别的，等老王返岗再说。他孩子退烧了没，我不知道。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!