【问题标题】:What does ERR_SPDY_PROTOCOL_ERROR mean in nginx?nginx 中的 ERR_SPDY_PROTOCOL_ERROR 是什么意思?
【发布时间】:2016-02-25 07:42:59
【问题描述】:

我和我的几个同事收到了net::ERR_SPDY_PROTOCOL_ERROR 错误。

我们使用 ngnix 版本 1.8.0。错误不稳定(难以复制),Ngnix错误日志没有这个错误。

您如何建议我们抓住并解决这个问题?

【问题讨论】:

    标签: nginx spdy


    【解决方案1】:

    我遇到了同样的问题,请检查 Nginx 分区/HDD 中是否有足够的空间,我们添加了一些,它对我们有用。

    【讨论】:

    • 这里有同样的问题。我的负载平衡服务器空间不足。
    【解决方案2】:

    这是 Chromium 浏览器与某些防病毒程序(例如 AVG 和 Avast)之间存在的已知问题,尤其是在使用 SSL 连接时。在用户端无法解决。防止此问题发生由网站开发人员负责。

    Web 开发人员的文档在这里:http://dev.chromium.org/spdy/spdy-best-practices

    以下是该文章中未具体提及的一些对开发人员有用的提示:

    • 在使用标头和重定向时要格外小心,尤其是 301 和 302 的
    • 将所有包含保存在与您的域名访问相同的目录中或目录下,而不是服务器中的目录之上。防病毒软件无法在那里访问它们。为了保护您的包含文件,请在包含目录中创建一个 .htaccess 文件并简单地写一行:拒绝所有
    • 启用 Gzip 压缩。如果您使用 cPanel,这可以在您的网站优化设置中完成。
    • 保持您的 .htaccess 文件简单。切换服务器输出以创建不同的文件扩展名并重定向用户客户端会产生不必要的冲突。

    根据我的经验,这个问题似乎只在使用 Sessions 存储和传递数据时出现。 Cookie、Get 和 Post 似乎没有受到影响。

    希望这会有所帮助。

    【讨论】:

    • SSL 和 gzip 不兼容。
    【解决方案3】:

    我有一个网站这样做,结果是有人忘记在 index.php 的第一行的 PHP 重定向中输入“Location:”,导致标题无效。显然只有 Chrome 关心,但其他浏览器仍然可以正常加载。

    【讨论】:

      【解决方案4】:

      似乎有很多潜在的原因。我今天打的是标题行

      add_header X-Frame-Options: 拒绝;

      由于某种原因,当前的 chrome 会使用 ssl+http2 来解决这个问题。其他 X-Frame 标头似乎没有问题。

      【讨论】:

      • chrome://net-internals 对调试也很有帮助
      • 上面标题行中的问题似乎是冒号,根据nginx documentation,它不应该存在。我遇到了同样的问题,似乎 http2 解析器更加严格,不再忽略冒号。 (另见:trac.nginx.org/nginx/ticket/1409
      【解决方案5】:

      与 OP 一样,这对我来说是一个间歇性问题,并且只发生在大小 > 2mb 的 AJAX 请求上。

      在我们从 AWS 经典 ELB 迁移到 ALB 后,问题开始出现。

      我通过卸载 Chrome,删除我的用户配置文件(在 mac 上删除 ~/Library/Application Support/Google/Chrome 的内容),然后重新安装解决了这个问题。

      【讨论】:

        【解决方案6】:

        我最近在服务器升级后看到了这个错误。

        我在 Chrome 中的所有用户都能看到它,但只是间歇性的。

        通过让所有用户使用 Chrome 的“空缓存和硬重新加载”刷新功能,我能够为所有用户解决此问题。 (Chrome 工具 F12,右键刷新按钮)

        我怀疑它与正在使用的 SSL 证书的缓存有关。

        【讨论】:

          【解决方案7】:

          对我来说,是 Nginx 配置不允许使用 OPTIONS 方法。我只将 GET|PUT|POST|DELETE 列入白名单,所以当 Chrome 尝试发送 OPTIONS 方法时,天知道为什么**,错误被重现。

          打开 Firefox 并重复请求,然后查看网络检查器以检查是否正在发送任何 OPTIONS 请求。

          ** 可能用于检查 X-Frame-Options 或 HSTS 验证。

          【讨论】:

            【解决方案8】:

            TL;DR:如果您正在缓存资产,请检查您的 nginx 服务器上的驱动器空间。

            我们的场景

            我不确定在哪里发布我的答案,因为在 Chrome 中获取 ERR_SPDY_PROTOCOL_ERROR 时可能是一个边缘情况(以及在 Firefox 中等效的“加载资源失败”错误)。但是这篇文章帮助我缩小了罪魁祸首。它不是标题、gzip、重定向或 adblock/ublock。

            我们从机器上部署了 2 个 Web 应用程序,它们都运行得非常好。最近,我们部署了一个对缓存资产进行更改的应用程序。部署完成后,我们立即从 Chrome 中获得了ERR_SPDY_PROTOCOL_ERROR。有趣的是,它收到了HTTP 200,如果您直接导航到该资产,Chrome 将呈现该资产。但是,在页面上加载资源会导致它失败。

            有趣的是,另一个 Web 应用程序非常好。调查 Chrome 上的网络内部结构,我们发现服务器正在关闭连接。几个小时后,我们确定这是因为我们的 nginx 服务器已用完驱动器空间。我不知道为什么当您直接导航到资产时会导致资产正确加载,但在加载页面时会失败,但清除空间会立即解决问题。

            【讨论】:

              【解决方案9】:

              从其他答案中可以看出,很多不同的事情都可能导致这种情况。对我来说,我有一个格式错误的标题,其他浏览器只是忽略了(额外的:)。唯一的答案是调试提示,在加载损坏的页面时检查 Chrome 的 net-internals 事件:chrome://net-internals/#events

              对我来说,当我看到这一行时,我就知道这是标题问题

              t=65422 [st=53]      HTTP_TRANSACTION_READ_HEADERS  [dt=4]
                               --> net_error = -337 (ERR_SPDY_PROTOCOL_ERROR) 
              

              从响应头中删除多余的: 后,HTTP/2 开始在 Chrome 中工作。我建议从您的服务器获取原始响应并进行非常仔细的检查以确保没有语法错误。

              【讨论】:

                【解决方案10】:

                我在尝试为我在 Chrome 上使用 ERR_SPDY_PROTOCOL_ERROR 所面临的问题寻求帮助时遇到了这个问题。认为这可能会使其他人受益。

                我们的情况/解决方案:我们使用连接到 EC2 实例的 AWS Application Load Balancer。我们在 EC2 代理上运行的脚本之一是来自客户端浏览器的请求。我们最近更新了脚本 - 没有相关更改 - 并注意到 Chrome 和 Safari 对代理脚本的请求都开始失败。 Chrome 显示了ERR_SPDY_PROTOCOL_ERROR 错误,当我们深入研究它时,我们可以看到这个请求使用的是 HTTP/2。 Firefox 请求继续正常工作。

                我们的解决方案:我们关闭了 ALB 中的 HTTP/2 支持。马上解决了问题。

                AWS CLI 命令:

                aws elbv2 modify-load-balancer-attributes --load-balancer-arn <your_load_balancer_arn> --attributes Key=routing.http2.enabled,Value=false
                

                【讨论】:

                  【解决方案11】:

                  检查您的代理缓存路径的位置 - 检查它是否存在、是否有空间以及权限和所有者是否允许 nginx 进程写入该路径。

                  例如nginx.conf (sn-p)

                  proxy_cache_path /proxy_cache levels=1:2 keys_zone=danger_zone:10m inactive=60m;

                  ...然后检查/proxy_cache 路径是否由nginx 拥有和写入。

                  【讨论】:

                    【解决方案12】:

                    就我而言,我通过增加块大小解决了这个问题:

                    http2_chunk_size             300k;
                    

                    【讨论】:

                      【解决方案13】:

                      我们目前的结构是

                      AWS ELB=>Nginx=>JBoss

                      它提示我们同样的 crome 错误ERR_SPDY_PROTOCOL_ERROR

                      它在没有默认情况下由 ELB 启用的 http2 的情况下正常工作,我们不希望它被禁用。 经过进一步调查,我们注意到我们的 JBoss 服务器正在压缩响应。我们禁用它并且一切正常。

                      【讨论】:

                        【解决方案14】:

                        如果你得到了

                        ERR_HTTP2_PROTOCOL_ERROR

                        ERR_SPDY_PROTOCOL_ERROR

                        在 Chrome 或 Safari 浏览器中使用 Nginx Content-Security-Policy,首先通过访问 chrome 隐藏界面:chrome://net-internals/#events 并选择 HTTP/2 选项卡下的“实时 HTTP/2 会话”按钮来检查此问题。

                        如果您在刷新后对您的域产生以下结果:

                        HTTP2_SESSION_RECV_INVALID_HEADER

                        --> error = "标题名称中的字符无效。"

                        您应该使用以下方法编写 CSP 标头:

                        add_header Content-Security-Policy "<values>";
                        

                        这个方法对我很有效。

                        注意:CSP 中不允许使用空格。仅使用空格来区分策略参数及其值。要在 chrome 中重现此问题,您可以使用 add_header Content-Security-Policy: "&lt;values&gt;"; ,其中有额外的 : 将被视为无效。

                        【讨论】:

                        • 非常感谢!这就是我遇到的错误。原来我有一个类似的问题 - 设置标题“charset = utf-8”而不是“charset:utf-8”时出现拼写错误。
                        猜你喜欢
                        • 1970-01-01
                        • 2011-08-18
                        • 2021-03-29
                        • 1970-01-01
                        • 2011-08-12
                        • 2017-06-11
                        • 2018-03-05
                        • 2023-03-27
                        • 1970-01-01
                        相关资源
                        最近更新 更多