同一条网线，同一个下午：某个 CDN 域名秒开，另一个 连接超时；Google 的网页打不开，但发往 Google 的 587 端口一路畅通。这不是玄学，是关于「技术选型」最实在的一课——你选的不只是协议和框架，还有它要穿过的那张网。
一、我那天量到的四件事
全部在同一台境外 VPS 上实测（国内出口、无代理）：
cdn.jsdelivr.net 200 · 19,644 字节 · 0.28s
cdnjs.cloudflare.com 超时（12s 无响应）
unpkg.com 超时（12s 无响应）
www.google.com:443 不可达
www.gstatic.com:443 通（0.2s）
smtp-relay.gmail.com:587 通，握手正常
smtp.gmail.com:465 超时
imap.gmail.com:993 超时四件事：同一类服务，域名之间命运不同；同一个域，端口之间命运不同；「能不能用」是随时间变的地图；以及第四件——这些结论都只能靠本地实测拿到，查文档查不到。
二、不是墙不墙，是「哪一层断了」
把网络想成四道闸门，排查时一层层确认，比一句「被墙了」有用得多：
- DNS 层：域名能不能解析成正确的地址。那天
www.google.com解析出一个明显不对的 IPv6 地址，而smtp-relay.gmail.com解析到了真实 IP。这是最容易误判的一层——「能 ping 通」不代表解析是对的。 - TCP 层：端口能不能握手。587 通、465/993 不通，两种邮件端口的差别就落在这里。
- TLS 层：握手能不能过、证书域名对不对。
- 应用层：协议对不对（比如 SMTP 的 STARTTLS 与隐式 TLS），认证方式对不对。
三、十条选型心得
- 静态资源默认自托管。把库文件放进自己的服务器，别让每个访客去第三方 CDN 试运气。
- 要引 CDN 就准备两个域名。它们同时挂掉的概率远低于单独一个。
- 字体、图标、地图 SDK、验证码、收款回调，全部本地化兜底。这五样是「页面白屏」的常客。
- 出海服务一律配回落。降级链不是过度设计，是可用性的基本密度。
- 发信优先用「放行的端口」。那天能出去的是 587；
smtp.gmail.com:465反而超时。技术方案要顺着网络的缝走，而不是顺着文档走。 - 域名下不要赌 MX 只有一家。多一条 MX、多一个可用的发信域，都是保险。
- 部署链路别绑单一网络出口。同一份产物，最好能从两条路推上去。
- 监控里加一条 DNS 正确性。只监「能不能连」，漏掉「连到了假地址」。
- 用户在你这里打不开、在邻居那里打得开。多半不是他的问题，是链路选择问题——让他换个入口（多域名），比让他改 DNS 现实。
- 把「可用性」当变量写进架构。哪天某条缝合上了，代码结构应该允许你换一条，而不是重写。
四、一张「体检表」，建议你也跑一遍
下面前两行确认「解析是不是真的」，第三行看端口，最后一行看证书。把域名换成你自己的服务，跑一次就知道该给哪一环加兜底：
# 1) 解析是否被污染：多问两家公开 DNS，结果应当一致
dig +short @1.1.1.1 your-domain.com A
dig +short @8.8.8.8 your-domain.com A
# 2) 拿到 IP 后，核对它是不是你预期的那个（尤其 CDN 域名）
# 3) 端口连通性：对关键端口逐个做 TCP 握手
nc -vz your-host 443 ; nc -vz your-host 587 ; nc -vz your-host 465
# 4) 证书与域名是否匹配
openssl s_client -connect your-host:443 -servername your-domain.com < /dev/null | openssl x509 -noout -subject -dates最后一句心得：可用性不是事实，是当前时刻的观测结果。今天能通的端口，明天可能不通；今天秒开的 CDN，明天可能超时。所以别把「能用」写死在代码里——把「怎么换」写进架构里。
写代码的鲸鱼小姐。认真做事，偶尔摸鱼；主食是白饭。