“http://www.xxx.com/ skipped. Content of size 67099 was truncated to 59363”这行日志我猜搞过爬虫、写过后端网关或者天天跟 HTTP 接口打交道的人多少都见过类似的东西。我第一次遇到时也是一脸懵好好的 URL 怎么说跳过就跳过了67099 字节为什么要给我截成 59363到底是网站出问题了还是我代码的锅先说结论这行日志本质上是一个“内容超限被丢弃”的提示最常见的出现场景是爬虫框架、反向代理、HTTP 调试工具或者日志采集链路。它想表达的意思很直白——某个地址的响应体原本有 67099 字节但因为超过了你或中间设备设定的阈值最终只保留了 59363 字节剩下的被砍掉于是这个 URL 被打上 skipped 标记不再继续处理。适合谁来参考后端开发者、爬虫工程师、运维以及所有需要排查接口响应异常的人。搞清楚它背后的大小校验机制和确认“被谁截断”的方法比背一个配置项重要得多。1. 从一行日志说起skipped 与 truncated 的语义拆解1.1 每个单词都在告诉你什么咱们把这行日志拆开看其实信息量非常大开头的http://www.xxx.com/是出问题的 URL正常应该是完整路径这里被脱敏了。skipped表示这个地址被跳过。注意是“跳过”而不是“报错”这说明系统不是崩溃了而是主动放弃了这个响应。在很多爬虫引擎和网关里对超限响应采取的策略就是“静默丢弃”只记一条 warning。Content of size 67099是原始内容的大小单位是字节约等于 65.5 KB。was truncated to 59363是截断后的大小约等于 58 KB。换算一下就清楚了67099 - 59363 7736 字节也就是约 7.5 KB 的内容被丢掉大约是原体积的 11.5%。这个比例并不算小如果一个接口文档被砍掉 11.5%很可能就丢了关键的 JSON 字段或者网页的核心 HTML 片段。1.2 “谁”可能输出这种日志这行日志不一定来自某一个固定的程序我实际碰到过好几种来源Python 爬虫框架或基于 Scrapy 的爬虫调度平台在中间件里检查响应体大小并丢弃超限内容。HTTP 抓包/调试工具比如 Fiddler、Burp Suite对超大响应做了预览截断。反向代理层比如 Nginx 在缓冲响应时触发了限制返回错误或者掐断连接。自己写的下载脚本用 curl 或 wget 设置了--max-filesize。日志采集链路Filebeat、Logstash或数据库驱动因为字段长度不够把长文本截断后记录了一条警告。不同的来源对应的排查方向完全不一样。这也是为什么我建议先不要改任何配置而是先判断这行日志到底是谁打的。1.3 先算明白这笔账我在处理这类问题时会先把数字记下来因为“截断到多少”这个数值非常关键。比如 59363 这个数字它往往对应某个配置里的阈值。假如你设置的是“响应体超过 58 KB 就截断”那么 59363 可能是阈值减去响应头或者编码开销后的值假如你设置的是“保留前 59363 字节”那它就是硬编码的裁剪长度。反过来如果截断后的数字是 6553664 KB那多半是底层缓冲区的默认大小如果是 1024 的整数倍也可能跟某个平台的内存页限制有关。总之截断结果数字的“规律性”会直接暴露限制来自哪一层这一点到后面实战环节特有用。2. 内容截断的底层机制五个“关卡”逐个拆既然要排查就得知道 HTTP 响应从服务器到客户端之间可能被哪些环节“动手脚”。我按数据流向整理成五个层级每一层都有各自的大小限制机制。2.1 客户端框架里的“硬顶”客户端代码是最容易背锅也最容易修复的一层。常见的情况Scrapy 里的DOWNLOAD_MAXSIZE默认值是 1073741824也就是 1 GB但很多公司内部的爬虫框架会把它改小来防止内存被打爆。一旦实际响应超过这个值Scrapy 就会丢弃响应体并打出类似 “Ignoring response ... Content length exceeds limit” 的日志。Node.js 的body-parser默认限制请求体是 100kb注意这是请求体不是响应体但如果你用 axios 做下载并设置了maxContentLength响应体也会被截断。Go 标准库里有http.MaxBytesReader一般用于限制请求体但服务端也可用它限制响应内容。curl 和 wget 都支持--max-filesize这个限制简单粗暴超了就报错退出。为什么客户端要设这种限制核心原因是防内存溢出。一个爬虫如果同时开着几十个并发请求每个响应急剧膨胀到几百 MB内存立刻就会被打穿。所以我不会说“限制是多余的”而是建议把限制设成一个合理值并让日志带出 URL 和大小方便事后分析。2.2 反向代理与网关的缓冲机制Nginx 这类反向代理很特殊它既管请求体也管响应体。很多同学只听说过client_max_body_size那是限制用户上传请求体的而响应体的大小和缓冲由另一组参数控制proxy_buffer_size 16k; proxy_buffers 8 4k; proxy_busy_buffers_size 16k; proxy_max_temp_file_size 1024m;Nginx 收到后端响应时proxy_buffer_size先用来读响应头然后proxy_buffers用来缓冲响应体。如果响应体超过了所有缓冲区的总和Nginx 会把剩余内容写到临时文件再由proxy_max_temp_file_size控制临时文件上限。一旦临时文件也超限Nginx 通常会直接掐断连接客户端看到的就是 502 或者连接中断。不过要注意一个细节Nginx 默认并不会“截断内容后继续转发”它更倾向于直接终止请求。所以如果你在客户端看到“截断到 59363”而前面挂着一层 Nginx那就得仔细看它是在缓冲阶段出问题还是后面的应用自己截断了。2.3 服务器端主动截断有时候根子就在自己的业务代码里。比如一个 Java 接口从数据库读出了很长的文本为了防止响应过大直接substring截断再返回或者一个 OpenAPI 模式的接口对maxLength做了限制服务端校验不过就只返回部分字段。还有更常见的PHP 的output_buffering或memory_limit导致脚本半路死掉返回不完整的 200 响应。这类截断有个特征响应头里可能写着 Content-Length: 59363因为服务端在返回前就已经把内容裁剪好了。如果你在客户端拿到的 Content-Length 就是截断后的值那么问题大概率在上游不用去排查自己的代码。2.4 日志采集与数据库字段很少人会把截断问题和数据库、日志队列联想到一起但实际工作中这类问题一点都不少。MySQL 把超长文本写入 varchar 字段时会报Data truncated for column content at row 1这其实也是“truncated”。日志系统里Filebeat 的单行日志默认最大长度是 1048576 字节1 MB超过会截断Logstash 对单个事件的默认上限是 10 MB。Kafka 的message.max.bytes如果设置成 1 MB超出消息会被直接丢掉报错信息里可能就有 “Record is too large”。这类截断通常和 HTTP 响应本身无关而是数据在链路里被“二次加工”时出的问题。关键判断方法是看日志产生的时间点和完整上下文如果日志采集器输出给下游的就是截断后的内容那问题就在采集配置上。2.5 调试工具与浏览器的“假截断”最有迷惑性的就是这一层因为数据本身没有丢只是工具显示不全但日志和界面上都写着 truncated。我遇到过几个典型场景Chrome DevTools 的 Network 面板对超大的响应默认不会一次性渲染全部内容需要点“View source”查看完整样式但有些版本对单次响应有显示上限。Postman 免费版在响应预览区域会截断大响应安装包和主体数据其实已经完整返回。Fiddler 开启自动响应解码时如果内容过大会提示响应体被截断用于性能优化。有的抓包工具对 WebSocket 和 chunked 编码支持不好看起来数据断了一截但实际上 TCP 流是完整的。“假截断”的危害在于你会花大量时间去调客户端和服务端的配置最后发现什么都没改只是工具显示的问题。所以我一再强调先用命令行工具复现再动配置后面第三部分会说具体怎么做。3. 实操排查三步定位截断发生在哪一层如果你也碰到类似日志别急着改代码。我总结了一套三步定位法跟着走基本能把问题锁死在某一层。3.1 第一步看一眼响应头绕开所有中间层用最原始的方式访问目标 URLcurl -sI http://www.xxx.com/重点看两个字段Content-Length是否等于 67099等于说明数据源头是完整的等于 59363 则说明源头已经被截断。Transfer-Encoding: chunked是否存在存在的话就没有 Content-Length说明内容边生成边发截断可能发生在传输中。Content-Encoding是否为 gzip 或 br如果服务端压缩了那么 67099 是压缩后的大小还是原始大小需要区分清楚。注意-I发的是 HEAD 请求部分服务端对 HEAD 和 GET 返回的 Content-Length 不一致这是正常的。如果怀疑就直接用curl -v发 GET 请求看完整响应头。3.2 第二步用 curl 复现原始响应执行curl -v -o /tmp/response.bin http://www.xxx.com/ 21 | tee /tmp/curl.log然后看输出文件大小ls -l /tmp/response.bin wc -c /tmp/response.bin如果文件大小是 67099说明网络传输链路是完整的问题在应用层或显示层。如果文件大小只有 59363再对比一下 curl 日志里有没有 “transfer closed with outstanding read data remaining” 之类的提示有的话说明连接中途被切断。还可以用xxd或tail快速检查文件结尾是不是完整的 JSON 花括号或 HTML 闭合标签判断是“正常结束”还是“被硬切”。tail -c 200 /tmp/response.bin如果结尾是一堆截断的半截字符串基本就是硬截断。3.3 第三步逐层代理抓包验证如果 curl 直连完整而你实际业务是走了 Nginx 或代理的那就在每一跳做同样验证。比如在业务服务器本地 curlhttp://127.0.0.1:8080看内容大小。在 Nginx 所在机器上 curl 后端地址看大小。在客户端 curl Nginx 对外地址看大小。哪一跳开始变小问题就出在哪一层。如果还查不出来上 tcpdump 抓包sudo tcpdump -i eth0 -w /tmp/http.pcap port 80 and host www.xxx.com抓完后用 Wireshark 追踪 TCP 流对比实际传输的字节数。TCP 层如果完整那就真和网络无关了。3.4 常见误判Content-Length 与 chunked 的坑这里特别提醒一个坑如果响应是 chunked 编码且内容很大客户端往往会因为“读取到某个阈值就主动断开”这时候抓包看到的 TCP 流其实是完整的但应用层只消费了前 N 字节。你不是在网络层丢数据而是在应用层主动中断。所以在抓包看到完整 TCP 流时别高兴得太早回到代码里检查是不是设置了类似maxContentLength、limit之类的参数。4. 五个真实场景的处理方案定位到具体层级之后处理起来就有针对性了。我挑了五个最常见的真实场景每个都给出了可落地的方案。4.1 场景一爬虫框架触发大小限制假设你用 Scrapy 爬取这个 URL日志里报 skipped多半是框架配置问题。先检查项目里的 settings.py# settings.py DOWNLOAD_MAXSIZE 0 # 0 表示不限制 DOWNLOAD_WARNSIZE 0 # 0 表示不警告如果不希望完全放开建议设一个较大的业务合理值比如 50 MBDOWNLOAD_MAXSIZE 52428800 # 50MB如果用 requests 自己写爬虫可以用流式读取 手动截断import requests url http://www.xxx.com/ with requests.get(url, streamTrue) as r: r.raise_for_status() max_size 67099 chunks [] total 0 for chunk in r.iter_content(chunk_size4096): chunks.append(chunk) total len(chunk) if total max_size: break content b.join(chunks)这样既能控制内存又不会因为超过Content-Length被 requests 主动拒绝。核心逻辑是流式读取不加载整个响应体靠手动控制总大小。4.2 场景二Nginx 反向代理缓冲调整如果 Nginx 是从后端起就截断或返回 502先调缓冲参数location / { proxy_pass http://backend_server; proxy_buffer_size 128k; proxy_buffers 4 256k; proxy_busy_buffers_size 256k; proxy_max_temp_file_size 1024m; proxy_temp_file_write_size 64k; }proxy_buffer_size原先默认只有 16k如果后端返回的响应头就很大或者响应体没有足够缓冲就很容易触发问题。调完后记得 reloadnginx -t nginx -s reload注意这些参数主要解决“响应体大导致缓冲不够”的问题如果你是想限制请求体大小才用client_max_body_size不要把两者混在一起调。4.3 场景三调试代理与浏览器开发者工具如果你是在抓包工具里看到截断先区分是显示层还是数据层。在 Fiddler 里可以写一段规则去掉响应大小限制// FiddlerScript if (oSession.isHTTP oSession.oResponse.pieceCount() 100) { oSession.bBufferResponse false; }或者直接禁用“智能解码”选项用 Raw 模式看完整数据。Chrome DevTools 里遇到超大响应时右键响应内容选择 “Save to file”或者用命令行导出 HARcurl -H Accept: application/json http://www.xxx.com/ full_response.json这一步能确认浏览器显示之外的“真实数据”。4.4 场景四日志系统与数据库字段截断如果是 Filebeat 把日志截断了调整 filebeat.ymlfilebeat.inputs: - type: filestream max_bytes: 10485760 # 10MB如果是 MySQL 写入超长报错要么改字段类型要么在写入前做截断校验ALTER TABLE article MODIFY COLUMN content MEDIUMTEXT;应用层写一个统一的截断工具避免不同业务各自处理导致截断位置不一致。数据库截断和 HTTP 截断经常同时出现比如你存了一篇文章MySQL 字段是 varchar(60000)页面接口返回的 Content-Length 变成 59363就是因为入库时被截断过一次。所以排查时也别忽略数据库那一层。4.5 场景五确认是“假截断”最后再强调一次有些截断真的只是“看着像”。我遇到过最典型的一次是一堆 URL 都报 skipped结果发现是爬虫框架对重复 URL 的 URL 指纹做了去重压根没发请求日志里只是沿用了 “skipped” 字样跟内容截断毫无关系。所以排查时先确认“有没有真正发 HTTP 请求”。用访问日志或者 tcpdump 看一眼如果根本没有 TCP 连接那和 truncated 无关是调度策略或去重策略的问题。5. 常见问题速查与避坑心得5.1 问题速查表现象可能原因排查方法解决方案日志显示 skipped客户端收到 59363 字节客户端框架设置响应体大小限制检查 Scrapy、requests、curl 配置调大或关闭 maxsize 限制直连 curl 完整走 Nginx 就小一截Nginx proxy buffer 或 temp file 限制分层 curl 对比大小调大 proxy_buffer_sizeContent-Length 本身就是 59363服务端先截断再返回查看后端日志与压测工具修服务端接口逻辑日志里出现 Data truncated for column数据库字段长度不足直接看 DB 表结构改字段类型为 TEXT/MEDIUMTEXT工具界面看到 truncated但文件保存完整调试工具显示限制用 curl 或文件导出验证忽略显示截断或改工具配置大量 URL 全部 skipped但截断数值不同去重策略或调度策略查框架运行状态、去重队列检查爬虫调度逻辑chunked 响应总在中途断客户端主动断开Wireshark 抓包看 TCP 流修改应用层读取策略5.2 我踩过的几个坑第一千万别一看到 truncated 就怀疑网络。网络丢包一般会表现为连接中断、read reset而不是规规矩矩地把内容裁成 59363。能精确截断到某个字节数的一定是某一层“主动做减法”。第二数值一定要记下来。我排查过一个诡异问题所有响应都被截断到 8192后来发现是一台网关设备的默认 buffer 大小跟应用层毫无关系。你记下了数值搜索的时候直接搜这个数能极快地命中原因。第三区分“内容大小”和“文件大小”。有时候服务端返回 67099 字节的文本但因为 HTTP 头里带了 Content-Encoding: gzip实际传输的只有 59000 多字节客户端解压后是 67099。这种场景下如果只看 Content-Length 会被误导。第四很多内部爬虫框架的 “skipped” 日志打印的不是真实 URL而是脱敏后的地址。这就导致排查看不到具体是哪个地址出问题。最好在框架里加一行上下文输出下载前和后的大小对比方便复盘。5.3 排查完后的复盘建议问题解决之后我会建议统一做三件事给响应大小限制加监控。不管限制设成多少只要出现超过阈值的 URL就发一条告警而不是静默 skipped。给日志补上“截断前大小/截断后大小/限制阈值”三个字段。有了这三个数下次任何人看到日志都能秒懂。如果业务确实需要大量超过 50MB 的响应优先考虑改造接口——分页、压缩、或者改成文件下载地址比无脑调大限制健康得多。我个人的习惯是排查完这类问题后顺手把目标 URL 和复现命令贴到团队的排障手册里。因为这类截断问题的特征非常相似但每次暴露出来的层级可能完全不同手册里每多一条案例下次别人就能少踩一次坑。最后分享一个小技巧当你不确定截断到底发生在哪一环时用“最小链路法”测试。先让服务端直接返回写死的完整 67099 字节内容再用同样的客户端代码去拉取。如果完整说明你的代码没问题如果还是截断那肯定是客户端的读取逻辑有限制。用这个方法排除干扰项往往比翻遍所有配置更快、更可靠。