2002 年，美国北卡罗来纳州一所大学发生了一件看似荒诞的网络故障：统计系的邮件服务器，只能向 500 英里以内的服务器正常发邮件。

统计系主任最初发现，邮件发送似乎存在一道神秘的“距离边界”：里士满、亚特兰大、华盛顿等地可以正常发送，但孟菲斯、波士顿、底特律等更远地区却几乎全部失败。统计系甚至请地理学家绘制地图，发现故障范围竟然真的接近一个以办公室为圆心、半径约 500 英里的圆。

管理员 Trey Harris 随后发现，真正决定邮件能否发送的并不是收件人住在哪里，而是对方邮件服务器在哪里。一位朋友虽然住在北卡，但邮件服务器部署在西雅图，邮件同样无法送达。

最终，发现问题出在一次系统升级：
顾问升级 SunOS 时，意外将新版 Sendmail 降级成了旧版本，却继续使用新版配置文件。
旧版程序无法识别部分新配置项，便悄悄忽略了它们，导致 SMTP 连接超时时间异常变成了接近 3 毫秒。

3 毫秒究竟有多短？TCP 建立连接需要经过网络传输，而数据传输速度受光速和网络设备延迟限制。距离较近的服务器，TCP 握手还能勉强在超时前完成；距离更远时，程序已经主动放弃连接。于是，一个普通的配置兼容性问题，最终表现成了仿佛系统“认识地理距离”的 500 英里边界。

这个故事也成为网络排障的经典案例：系统表面的异常现象，背后往往不是玄学，而是软件配置、网络协议和物理规律共同作用的结果。
给开发者的另一个教训是：程序异常之后，系统保持静默，按照错误的规则运行，比报错糟糕得多。