当内容长度介于 4013-8092 个字符之间时，Google Cloud Run 网站会超时。到底是怎么回事？

Posted 2023-02-24

【中文标题】当内容长度介于 4013-8092 个字符之间时，Google Cloud Run 网站会超时。到底是怎么回事？

【英文标题】：Google Cloud Run website timeouts when content length is between 4013-8092 characters. What is going on?

【发布时间】：2020-11-24 19:30:16

【问题描述】：

此问题发生在由 nginx 和 php-FPM 提供的纯 PHP 文件上。我在使用 Symfony 开发我的网站时偶然发现了这个问题，但有问题的内容长度范围是 3702-15965（我想知道为什么它与普通 PHP 不同）。

到目前为止我已经尝试过：

超时持续时间为 15 秒，但我尝试将其增加到 300 秒，但仍然超时。所以我猜这是无限循环的东西。 它看起来与资源无关，因为即使内容长度为 500 万个字符，它也能正常工作。 用不同的字符创建了各种测试，看看我是否可以改变有问题的内容长度范围。答案是否定的，我所有测试的范围都保持不变。 我已尝试禁用 gzip。它没有改变长度范围，但响应发生了变化。 Gzip 启用响应：“上游请求超时”| Gzip 禁用响应：完全空白

注意事项：

我的本地主机上不存在此问题。 它

很少

正常打开页面。我无法始终如一地重现这一点。 除了“请求超时”行之外，Nginx、PHP 或 GCR 日志中没有错误。

感谢任何帮助。谢谢。

【参考方案1】：

有趣的是，我在写问题时已经解决了这个问题。在 Nginx 配置中添加 fastcgi_buffering off; 可以解决此问题。

但我仍然不明白问题出在哪里以及为什么禁用缓冲可以解决问题。因此，如果有人可以解释，我不介意将该答案标记为解决方案。

【讨论】：

有趣的是，我最近遇到了类似的事情。事实证明，我发送的数据超出了 fastcgi_buffer_size 缓冲区的容量（我的响应为 50KB）。碰撞 fastcgi_buffer_size（连同 fastcgi_buffers 和 fastcgi_busy_buffers_size）让我可以继续缓冲并使一切正常工作。

【参考方案2】：

这是特定于 nginx 而不是 Cloud Run。当 nginx 开始接收来自 FastGCI 后端的响应时，它将在内存中缓冲标头响应。如果响应对于内存来说太大，可以将其中的一部分保存到磁盘上的临时文件中，该文件由其他变量控制，如here 所述。通过禁用 fastcgi_buffering，响应在收到时同步传递给客户端。您可以在这些文章中找到更多信息[1][2][3]

[1]upstream sent too big header while reading response header from upstream

[2]Nginx upstream sent too big header while reading response header from upstream

[3]https://gist.github.com/magnetikonline/11312172#determine-fastcgi-response-sizes

【讨论】：

感谢您的链接，但我认为这并不能解释为什么仅内容在 4013-8092 个字符之间（或使用 Symfony 时为 3702-15965）时才会发生超时。