large_client_header_buffers 如何使用

eric.zc0423

我在Nginx Log可看到很多400 Bad Request, 有人建议调整large_client_header_buffers 值来去修复400.

我调整值之后，后端Node发起Post会很慢，而且有时浏览器端会出现504，同样nginx 也出现了timeout.

我的架构是 Nginx-->Haproxy--->APACHE--->JavaWEB.

agentzh

Hello!

2015-09-25 16:13 GMT+08:00 Eric Zhang:
> 我在Nginx Log可看到很多400 Bad Request, 有人建议调整large_client_header_buffers 值
> 来去修复400.
>

呃，这个 large_client_header_buffers 的配置与 400 错误没有任何关系。如果请求头过大，nginx 应该返回
494 Request Header Too Large.

> 我调整值之后，后端Node发起Post会很慢，而且有时浏览器端会出现504，同样nginx 也出现了timeout.
>

或许后端在处理较大的请求时很吃力？

> 我的架构是 Nginx-->Haproxy--->APACHE--->JavaWEB.
>

好复杂的流程。我觉得最好只保留一个 nginx :)

Regards,
-agentzh

eric.zc0423

Thanks Yichun Zhang.

> 我调整值之后，后端Node发起Post会很慢，而且有时浏览器端会出现504，同样nginx 也出现了timeout.
>

%%或许后端在处理较大的请求时很吃力？

%%Post的文件很小，http header和内容只有1.7KB。而且后端节点的负载都很低，服务器资源使用率不足10%。当时还发现，如果使用国外的主机访问网站，则不会出现这样的问题，Post返回值则是200.

> 我的架构是 Nginx-->Haproxy--->APACHE--->JavaWEB.
>

%%好复杂的流程。我觉得最好只保留一个 nginx :)

%%这个项目的Infra是两年前设计的，当时Haproxy不支持 SSL，所以Nginx+Haproxy做为负载均衡器。我又是刚刚接手运维，所以对于今天发生的情况，很难找到问题的原因。

2015-09-25 18:15 GMT+08:00 Yichun Zhang (agentzh) <age...@gmail.com>:

Hello!

2015-09-25 16:13 GMT+08:00 Eric Zhang:
> 我在Nginx Log可看到很多400 Bad Request, 有人建议调整large_client_header_buffers 值
> 来去修复400.
>

呃，这个 large_client_header_buffers 的配置与 400 错误没有任何关系。如果请求头过大，nginx 应该返回
494 Request Header Too Large.

> 我调整值之后，后端Node发起Post会很慢，而且有时浏览器端会出现504，同样nginx 也出现了timeout.
>

或许后端在处理较大的请求时很吃力？

> 我的架构是 Nginx-->Haproxy--->APACHE--->JavaWEB.
>

好复杂的流程。我觉得最好只保留一个 nginx :)

Regards,
-agentzh

--

Eric Zhang 張超

Mobile +8615000723581

agentzh

Hello!

2015-09-25 21:03 GMT+08:00 Eric Zhang:
>> 我调整值之后，后端Node发起Post会很慢，而且有时浏览器端会出现504，同样nginx 也出现了timeout.
>>
>
> %%或许后端在处理较大的请求时很吃力？
>
> %%Post的文件很小，http
> header和内容只有1.7KB。而且后端节点的负载都很低，服务器资源使用率不足10%。当时还发现，如果使用国外的主机访问网站，则不会出现这样的问题，Post返回值则是200.
>

我建议你直接分析 400 错误（以及 504
后端超时错误）的真实原因，而不是不断地调整并不相干的配置指令来试错（毕竟无针对性的试错很可能误判结果，也许现象和你的修改之间根本不存在因果联系）。

分析 400 的原因可以借助很简单的 systemtap 工具。比如使用我的 stap++ 脚本工具 [1]：

    $ stap++ -x 5478 -e 'probe @pfunc(ngx_http_finalize_request) { if
($rc == 400) { print_ubacktrace() exit() } }'

这可以在线上实时打印出 nginx worker 进程 5478 在遇到第一个触发 400 响应的请求时的 C
调用栈轨迹。这个信息可以直接为进一步的调试分析指明方向。

一次典型的输出如下：

 0x44b1b0 : ngx_http_finalize_request+0x0/0x4e0
[/usr/local/openresty/nginx/sbin/nginx]
 0x44c76f : ngx_http_process_request_line+0x1ff/0x350
[/usr/local/openresty/nginx/sbin/nginx]
 0x43841b : ngx_epoll_process_events+0x2ab/0x2d0
[/usr/local/openresty/nginx/sbin/nginx]
 0x430e13 : ngx_process_events_and_timers+0x53/0x130
[/usr/local/openresty/nginx/sbin/nginx]
 0x4365cd : ngx_worker_process_cycle+0xad/0x190
[/usr/local/openresty/nginx/sbin/nginx]
 0x435040 : ngx_spawn_process+0x150/0x510
[/usr/local/openresty/nginx/sbin/nginx]
 0x4376b4 : ngx_master_process_cycle+0x6d4/0x980
[/usr/local/openresty/nginx/sbin/nginx]
 0x4191ea : main+0x9ca/0xbb0 [/usr/local/openresty/nginx/sbin/nginx]
 0x7fec767ef700 : __libc_start_main+0xf0/0x1d0 [/usr/lib64/libc-2.21.so]
 0x4193f9 : _start+0x29/0x30 [/usr/local/openresty/nginx/sbin/nginx]

显然，nginx 在解析来自客户端的第一行请求数据时就发现了错误。于是对于此样本来说，客户端发起了一个不合法的请求行，比如
aasdgdfds 这样的，而合法的请求行则应该是类似

    GET /index.html HTTP/1.1

这样的。

Regards,
-agentzh

[1] https://github.com/openresty/stapxx

eric.zc0423

HI,

谢谢，我下周将试一下。

2015-09-25 21:19 GMT+08:00 Yichun Zhang (agentzh) <age...@gmail.com>:

Hello!

2015-09-25 21:03 GMT+08:00 Eric Zhang:
>> 我调整值之后，后端Node发起Post会很慢，而且有时浏览器端会出现504，同样nginx 也出现了timeout.
>>
>
> %%或许后端在处理较大的请求时很吃力？
>
> %%Post的文件很小，http
> header和内容只有1.7KB。而且后端节点的负载都很低，服务器资源使用率不足10%。当时还发现，如果使用国外的主机访问网站，则不会出现这样的问题，Post返回值则是200.
>

我建议你直接分析 400 错误（以及 504
后端超时错误）的真实原因，而不是不断地调整并不相干的配置指令来试错（毕竟无针对性的试错很可能误判结果，也许现象和你的修改之间根本不存在因果联系）。

分析 400 的原因可以借助很简单的 systemtap 工具。比如使用我的 stap++ 脚本工具 [1]：

$ stap++ -x 5478 -e 'probe @pfunc(ngx_http_finalize_request) { if
($rc == 400) { print_ubacktrace() exit() } }'

这可以在线上实时打印出 nginx worker 进程 5478 在遇到第一个触发 400 响应的请求时的 C
调用栈轨迹。这个信息可以直接为进一步的调试分析指明方向。

一次典型的输出如下：

0x44b1b0 : ngx_http_finalize_request+0x0/0x4e0
[/usr/local/openresty/nginx/sbin/nginx]
0x44c76f : ngx_http_process_request_line+0x1ff/0x350
[/usr/local/openresty/nginx/sbin/nginx]
0x43841b : ngx_epoll_process_events+0x2ab/0x2d0
[/usr/local/openresty/nginx/sbin/nginx]
0x430e13 : ngx_process_events_and_timers+0x53/0x130
[/usr/local/openresty/nginx/sbin/nginx]
0x4365cd : ngx_worker_process_cycle+0xad/0x190
[/usr/local/openresty/nginx/sbin/nginx]
0x435040 : ngx_spawn_process+0x150/0x510
[/usr/local/openresty/nginx/sbin/nginx]
0x4376b4 : ngx_master_process_cycle+0x6d4/0x980
[/usr/local/openresty/nginx/sbin/nginx]
0x4191ea : main+0x9ca/0xbb0 [/usr/local/openresty/nginx/sbin/nginx]
0x7fec767ef700 : __libc_start_main+0xf0/0x1d0 [/usr/lib64/libc-2.21.so]
0x4193f9 : _start+0x29/0x30 [/usr/local/openresty/nginx/sbin/nginx]

显然，nginx 在解析来自客户端的第一行请求数据时就发现了错误。于是对于此样本来说，客户端发起了一个不合法的请求行，比如
aasdgdfds 这样的，而合法的请求行则应该是类似

GET /index.html HTTP/1.1

这样的。

Regards,
-agentzh

[1] https://github.com/openresty/stapxx

--

Eric Zhang 張超

Mobile +8615000723581