net::ERR_SPDY_PROTOCOL_ERROR 错误 h2 协议，这个具体是什么引起的？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

V2EX 提问指南

这是一个创建于 2496 天前的主题，其中的信息可能已经有所发展或是发生改变。

互联网检索了下，很多同类问题
[img]

[/img]
[img]

[/img]

错误日志信息
3115: URL_REQUEST
https://att.itzmx.com/static/image/smiley/comcom/26.gif
Start Time: 2018-01-22 00:36:33.157

t=40602 [st= 0] +REQUEST_ALIVE [dt=360]
--> priority = "LOWEST"
--> url = "https://att.itzmx.com/static/image/smiley/comcom/26.gif"
t=40602 [st= 0] +URL_REQUEST_DELEGATE [dt=11]
t=40602 [st= 0] DELEGATE_INFO [dt=11]
--> delegate_blocked_by = "扩展程序“广告终结者”"
t=40613 [st= 11] -URL_REQUEST_DELEGATE
t=40613 [st= 11] +URL_REQUEST_START_JOB [dt=349]
--> load_flags = 33026 (BYPASS_CACHE | MAYBE_USER_GESTURE | VERIFY_EV_CERT)
--> method = "GET"
--> url = "https://att.itzmx.com/static/image/smiley/comcom/26.gif"
t=40613 [st= 11] URL_REQUEST_DELEGATE [dt=0]
t=40613 [st= 11] HTTP_CACHE_GET_BACKEND [dt=0]
t=40613 [st= 11] HTTP_CACHE_DOOM_ENTRY [dt=0]
--> net_error = -2 (ERR_FAILED)
t=40613 [st= 11] HTTP_CACHE_CREATE_ENTRY [dt=1]
t=40614 [st= 12] HTTP_CACHE_ADD_TO_ENTRY [dt=0]
t=40614 [st= 12] +HTTP_STREAM_REQUEST [dt=1]
t=40614 [st= 12] HTTP_STREAM_JOB_CONTROLLER_BOUND
--> source_dependency = 3205 (HTTP_STREAM_JOB_CONTROLLER)
t=40615 [st= 13] HTTP_STREAM_REQUEST_BOUND_TO_JOB
--> source_dependency = 3216 (HTTP_STREAM_JOB)
t=40615 [st= 13] -HTTP_STREAM_REQUEST
t=40615 [st= 13] +HTTP_TRANSACTION_SEND_REQUEST [dt=2]
t=40615 [st= 13] HTTP_TRANSACTION_HTTP2_SEND_REQUEST_HEADERS
--> :authority: att.itzmx.com
:method: GET
:path: /static/image/smiley/comcom/26.gif
:scheme: https
accept: image/webp,image/apng,image/*,*/*;q=0.8
accept-encoding: gzip, deflate, br
accept-language: zh-CN,zh;q=0.9
cache-control: no-cache
cookie: [1453 bytes were stripped]
dnt: 1
pragma: no-cache
referer: http://bbs.itzmx.com/thread-20831-1-1.html
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36
t=40617 [st= 15] -HTTP_TRANSACTION_SEND_REQUEST
t=40617 [st= 15] +HTTP_TRANSACTION_READ_HEADERS [dt=345]
t=40620 [st= 18] URL_REQUEST_SET_PRIORITY
--> priority = "MEDIUM"
t=40962 [st=360] -HTTP_TRANSACTION_READ_HEADERS
--> net_error = -337 (ERR_SPDY_PROTOCOL_ERROR)
t=40962 [st=360] -URL_REQUEST_START_JOB
--> net_error = -337 (ERR_SPDY_PROTOCOL_ERROR)
t=40962 [st=360] URL_REQUEST_DELEGATE [dt=0]
t=40962 [st=360] -REQUEST_ALIVE
--> net_error = -337 (ERR_SPDY_PROTOCOL_ERROR)

正常日志
3111: URL_REQUEST
https://att.itzmx.com/static/image/smiley/comcom/5.gif
Start Time: 2018-01-22 00:36:33.156

t=40601 [st= 0] +REQUEST_ALIVE [dt=507]
--> priority = "LOWEST"
--> url = "https://att.itzmx.com/static/image/smiley/comcom/5.gif"
t=40601 [st= 0] +URL_REQUEST_DELEGATE [dt=11]
t=40601 [st= 0] DELEGATE_INFO [dt=11]
--> delegate_blocked_by = "扩展程序“广告终结者”"
t=40612 [st= 11] -URL_REQUEST_DELEGATE
t=40612 [st= 11] +URL_REQUEST_START_JOB [dt=495]
--> load_flags = 33026 (BYPASS_CACHE | MAYBE_USER_GESTURE | VERIFY_EV_CERT)
--> method = "GET"
--> url = "https://att.itzmx.com/static/image/smiley/comcom/5.gif"
t=40612 [st= 11] URL_REQUEST_DELEGATE [dt=0]
t=40612 [st= 11] HTTP_CACHE_GET_BACKEND [dt=0]
t=40612 [st= 11] HTTP_CACHE_DOOM_ENTRY [dt=1]
--> net_error = -2 (ERR_FAILED)
t=40613 [st= 12] HTTP_CACHE_CREATE_ENTRY [dt=0]
t=40613 [st= 12] HTTP_CACHE_ADD_TO_ENTRY [dt=0]
t=40613 [st= 12] +HTTP_STREAM_REQUEST [dt=2]
t=40613 [st= 12] HTTP_STREAM_JOB_CONTROLLER_BOUND
--> source_dependency = 3199 (HTTP_STREAM_JOB_CONTROLLER)
t=40615 [st= 14] HTTP_STREAM_REQUEST_BOUND_TO_JOB
--> source_dependency = 3212 (HTTP_STREAM_JOB)
t=40615 [st= 14] -HTTP_STREAM_REQUEST
t=40615 [st= 14] +HTTP_TRANSACTION_SEND_REQUEST [dt=2]
t=40615 [st= 14] HTTP_TRANSACTION_HTTP2_SEND_REQUEST_HEADERS
--> :authority: att.itzmx.com
:method: GET
:path: /static/image/smiley/comcom/5.gif
:scheme: https
accept: image/webp,image/apng,image/*,*/*;q=0.8
accept-encoding: gzip, deflate, br
accept-language: zh-CN,zh;q=0.9
cache-control: no-cache
cookie: [1453 bytes were stripped]
dnt: 1
pragma: no-cache
referer: http://bbs.itzmx.com/thread-20831-1-1.html
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36
t=40617 [st= 16] -HTTP_TRANSACTION_SEND_REQUEST
t=40617 [st= 16] +HTTP_TRANSACTION_READ_HEADERS [dt=489]
t=40620 [st= 19] URL_REQUEST_SET_PRIORITY
--> priority = "MEDIUM"
t=41106 [st=505] HTTP_TRANSACTION_READ_RESPONSE_HEADERS
--> HTTP/1.1 200
status: 200
strict-transport-security: max-age=31104000
cache-control: max-age=259200
server: kangle/sakura/itzmx
date: Sun, 21 Jan 2018 16:36:39 GMT
content-encoding: gzip
last-modified: Mon, 13 May 2013 08:25:50 GMT
content-type: image/gif
x-cache: HIT from kangle web server dedi
x-cache: MISS from Anti-DDoS
content-length: 1644
t=41106 [st=505] -HTTP_TRANSACTION_READ_HEADERS
t=41106 [st=505] +HTTP_CACHE_WRITE_INFO [dt=0]
t=41106 [st=505] HTTP2_STREAM_UPDATE_RECV_WINDOW
--> delta = -1644
--> stream_id = 347
--> window_size = 6289812
t=41106 [st=505] -HTTP_CACHE_WRITE_INFO
t=41106 [st=505] HTTP_CACHE_WRITE_DATA [dt=0]
t=41106 [st=505] HTTP_CACHE_WRITE_INFO [dt=1]
t=41107 [st=506] URL_REQUEST_DELEGATE [dt=0]
t=41107 [st=506] URL_REQUEST_FILTERS_SET
--> filters = "GZIP"
t=41107 [st=506] -URL_REQUEST_START_JOB
t=41107 [st=506] URL_REQUEST_DELEGATE [dt=0]
t=41107 [st=506] HTTP_TRANSACTION_READ_BODY [dt=0]
t=41107 [st=506] HTTP_CACHE_WRITE_DATA [dt=1]
t=41108 [st=507] URL_REQUEST_JOB_BYTES_READ
--> byte_count = 1644
t=41108 [st=507] URL_REQUEST_JOB_FILTERED_BYTES_READ
--> byte_count = 2462
t=41108 [st=507] HTTP_TRANSACTION_READ_BODY [dt=0]
t=41108 [st=507] HTTP_CACHE_WRITE_DATA [dt=0]
t=41108 [st=507] -REQUEST_ALIVE

11 条回复 • 2018-01-23 18:02:31 +08:00

shuimugan

2018-01-22 01:43:08 +08:00

真巧这周在服务器上碰到了这个问题

现象是部分 php 页面突然输出不完整,结构是 1 台服务器跑 nginx 作反代,1 台跑 nginx+php

反代通过 http1.0 协议请求后端时,返回 200 以及不完整页面,
反代通过 http1./1 协议请求后端时,chrome 就报了这个 ERR_SPDY_PROTOCOL_ERROR

突然想起之前 nginx 好像修复过 proxy 相关的 bug,先升级到最新,问题依旧存在

直接看 php 那台服务器,查看 nginx 日志,发现是 fastcgi_temp 在的盘满了

起因是 php 那台服务器跑了个某云服务商自身控制面板就提供有的基础安全检测探针,结果探针有问题,强行更新 apt 某个库,连带更新 mysql,把 mysql 搞挂了,真是日了狗了

守护进程 PM2 日志默认写在系统盘,把系统盘写满了.nginx 也安装在系统盘,然后一些 php 页面返回比较大,需要创建几个 fastcgi_buffer,结果 fastcgi_temp 满了,无法创建 fastcgi_buffer,就只能返回不完整的页面

删了好几个 G 的 pm2 日志,留出空间,搞定...

仅供参考

1265578519

2018-01-22 01:54:34 +08:00

@shuimugan 啊咧，，我是启用 http2 的情况下，静态文件出现这个毛病，php 我没有通过 https，这个我不清楚是否存在这个问题，我和你的问题可能不相同？

shuimugan

2018-01-22 01:55:39 +08:00

@1265578519 #2 是不同的,需要查看 nginx 的 error.log,配合 curl,甚至抓包来排除

1265578519

2018-01-22 01:56:46 +08:00

@1265578519 嗯，也是在反代模式下出现，源服务器直接输出没存在问题，硬盘看了并没满。

1265578519

2018-01-22 02:16:06 +08:00

@shuimugan 刚看了反代服务端的日志，在前台出现 spdy 错误的时候，输出的内容 errno=[9 Bad file descriptor],socket=20(pool)，

Citrus

2018-01-22 08:42:17 +08:00 via iPhone

最好能发下 nginx 配置

0ZXYDDu796nVCFxq

2018-01-22 09:10:45 +08:00 via iPhone

升级 Nginx，某个版本之前的 http2 模块有 bug
为何还用 1.10.x ？现在 stable 已经是 1.12.2，mainline 已经是 1.13.8 ……

0ZXYDDu796nVCFxq

2018-01-22 09:13:00 +08:00 via iPhone

另外配置有问题，为何要对 image/gif 启用 gzip ……

1265578519

2018-01-22 18:39:42 +08:00

@gstqc 貌似是长连接时间太长了
反代服务器上游长连接大于源的长连接时间
我调整了加大源服务器的长连接为 120s 后，反代 60s，情况缓解很多，虽然偶尔可能还是会出现。
image，，一些图片内容还是有点压缩率的就开了。

1265578519

2018-01-22 18:42:13 +08:00

@gstqc 毕竟出现问题的还有 css js，肯定不是 gzip 毛病了，，，版本升级吗，最新版啊！那些图片是网络中检索的参考。代表很多人都出现这毛病

1265578519

2018-01-23 18:02:31 +08:00

问题终结，已解决