随机和偶然的网络错误（NSURLErrorDomain Code=-1001 和 NSURLErrorDomain Code=-1005）

Posted 2023-02-23

【中文标题】随机和偶然的网络错误（NSURLErrorDomain Code=-1001 和 NSURLErrorDomain Code=-1005）

【英文标题】：Random and occasional network error (NSURLErrorDomain Code=-1001 and NSURLErrorDomain Code=-1005)

【发布时间】：2015-12-06 17:23:08

【问题描述】：

最近几天我尝试从 d00m 调试网络错误。我开始用尽想法/线索，我希望其他 SO 用户拥有可能有用的宝贵经验。我希望能够提供所有相关信息，但我个人无法控制服务器环境。

这一切始于用户注意到我们应用中的几个“网络错误”。该错误似乎是随机发生的，没有任何与互联网连接、ios 版本或后端更新相关的明显模式。幕后发生的两个错误是：

Error Domain=NSURLErrorDomain Code=-1001 "The request timed out."

更频繁：

Error Domain=kCFErrorDomainCFNetwork Code=-1005 "The network connection was lost.

在调试了几天之后，我设法通过触发大约.向我们的后端发送 10 个随机（GET 和 POST）请求，每个请求之间有一个随机睡眠计时器（设置为 1-20 秒）。但是，它只发生在周期中。我最近几天经历的是，当“错误期”开始时，我每隔一两次运行代码就会遇到两个错误之一（意味着错误率为 1/10 或 1/20 的请求）。这种错误率会持续几个小时，然后错误会消失几个小时，然后重新开始。

关于设置的一些小知识：

发生在设备和模拟器上 在 iOS 8.4 和 iOS 7.1 上发生 - 尽管 v. 8.4 是我用于测试的主要版本。 我们使用NSURLSession 处理我们的网络请求。我们还包含 AFNetworking（更新到最新版本），但我们仅将安全部分用于 SSL 固定。即使 SSL 固定完全关闭，错误仍然存​​在。

我在过去几天写下的一些发现：

这似乎只发生在我们的生产环境中，它与我们的暂存环境有一些不同的配置。这让我认为它可能与here 和here 讨论的keep-alive 错误有关。但是，我们的运维部门已经设置了一个新的暂存环境，发送与生产环境相同的 keep-alive 标头，但这并没有使暂存环境发生错误。 我们的 android 版本应用无法使用相同的请求设置重现错误。此外，我们没有收到任何关于 Android 应用中“网络错误”的客户问题。

我的直觉说它与服务器环境和 iOS 中的 HTTP 实现有关。然而，我无法找到一个令人信服的模式来证明任何事情。我已经使用一个简单的 Rails 脚本进行了相同的设置，当下一个“错误期”发生时，我将准备好尝试在 iOS 领域之外重现它。发生这种情况时，我会更新问题。

我不是在寻找涉及重置 wifi 设置、关闭模拟器或类似的解决方案，因为我认为这在生产环境中不是可行的解决方案。我也考虑过进行 GitHub 问题中提到的重试循环修复，但我认为这是最后的手段。

如果您需要更多信息，请告诉我。

【问题讨论】：

你在使用 WebSocket 吗？

没有基本的NSURLSession 和NSURLSessionDataTask

嗨，Steffen，你解决了这个问题吗？

@NadaGamal 很遗憾没有。

【参考方案1】：

根据我的经验，这类问题通常会导致大量数据包丢失，尤其是在蜂窝网络上，多路径干扰和其他问题的微小变化可能会影响可靠通过流量与否。

想到的另一种可能性是 NAT 实施质量不佳，万一您的服务器的超时间隔长到足以导致 NAT 放弃 TCP 连接。

无论哪种方式，确定发生了什么的唯一方法是进行数据包跟踪。为此，请通过有线连接将 Mac 连接到 Internet，通过 Wi-Fi 启用网络共享，然后将 iOS 设备连接到该 Wi-Fi 网络。然后运行 ​​Wireshark 并告诉它监视网桥接口。这里的说明：

http://www.howtogeek.com/104278/how-to-use-wireshark-to-capture-filter-and-inspect-packets/

从那里，您应该能够准确地看到发送的内容和时间。这可能对理解它失败的原因大有帮助。

【讨论】：

感谢您的建议 - 如果这最终解决了这个谜团，我一定会调查并回复您。

【参考方案2】：

好的，我在调查类似问题上浪费了很多时间。

1005 可能是由已知的 iOS 错误引起的，并且有几个修复程序。例如添加标题 值为“关闭”的“连接”。 More info

1001 是另一回事。就我而言，问题是服务器上的奇怪（坏？）防火墙。当短时间内有很多（不是很多）请求时，它会禁止设备。

如果您遇到类似问题，我相信您可以轻松测试。

循环发送大量（取决于防火墙设置）请求（假设 1 秒内发送 50 个）。 关闭/终止应用程序（这将关闭与服务器的连接） （可选）稍等片刻（比如说 60 秒） 再次启动应用并尝试发送请求

如果您现在所有下一个请求都超时，您可能遇到同样的问题，您应该与服务器人员交谈。

PS：如果您无权访问服务器，您可以向用户提供信息，告诉他应该在设备上重新启动 wifi 以退出该超时循环。在某些情况下，这可能是最后的手段。