I can’t find documention anywhere on what it means when nginx shows 001
as
the value of $status in the access_log.
I currently use nginx as a reverse proxy and I get this error when
uploading
large files (2+ MB though my client_max_body_size is 4 MB) .
Also worth noting, the follow values per my log files:
$upstream_status: -
$upstream_response_time: -
$request_completion:
Right now, the nginx server sits behind a load balancer, so it goes:
Request
→ Load Balancer → Nginx → Origin.
Anyone have any ideas what the 001 code is supposed to represent?
Posted at Nginx Forum:
Hello!
On Wed, Apr 10, 2013 at 04:57:33PM -0400, abstein2 wrote:
$request_completion:
Right now, the nginx server sits behind a load balancer, so it goes: Request
→ Load Balancer → Nginx → Origin.
Anyone have any ideas what the 001 code is supposed to represent?
There is no special value “001” as used by nginx. It might be
something got from an upstream, but $upstream_status suggests it’s
not. You may try providing “nginx -V” output and debug log for a
deeper investigation, see Debugging | NGINX.
–
Maxim D.
http://nginx.org/en/donation.html
Sorry for the delay. I do think part of the issue is tied to the load
balancer since that connection is timing out (we set it very low for
testing
purposes), but the load balancer terminating the connection doesn’t
explain
why nginx is returning a 001 status code, since the connection from the
nginx box to the origin box shouldn’t be affected by that.
nginx -V:
nginx version: nginx/1.2.3
built by gcc 4.4.3 (Ubuntu 4.4.3-4ubuntu5.1)
TLS SNI support enabled
configure arguments: --prefix=/usr --sbin-path=/usr/sbin/nginx
–conf-path=/etc/nginx/nginx.conf --with-http_ssl_module
–with-http_gzip_static_module --error-log-path=/home/logs/error.log
–pid-path=/etc/nginx/nginx.pid --lock-path=/var/lock/nginx.lock
–with-http_geoip_module --with-http_addition_module
–with-http_sub_module
–with-http_stub_status_module --with-http_ssl_module --with-debug
–with-http_realip_module --with-http_perl_module
–add-module=/etc/nginx/yaoweibin-nginx-eval-module-706056b/
–add-module=/etc/nginx/yaoweibin-nginx_http_recaptcha_module-5d8f6b2/
–add-module=/etc/nginx/yaoweibin-nginx_secure_cookie_module-bcc69e5/
–add-module=/etc/nginx/ngx_http_redis-0.3.5/
–add-module=/etc/nginx/ngx_http_substitutions_filter_module/
–add-module=/etc/nginx/ngx_cache_purge-1.5/
–add-module=/etc/nginx/agentzh-redis2-nginx-module-1d79e5b/
–with-cc-opt=-Wno-error
Debug Log:
2013/04/16 15:38:37 [debug] 28029#0: *629969 rewrite phase: 3
2013/04/16 15:38:37 [debug] 28029#0: *629969 rewrite phase: 4
2013/04/16 15:38:37 [debug] 28029#0: *629969 post rewrite phase: 5
2013/04/16 15:38:37 [debug] 28029#0: *629969 generic phase: 6
2013/04/16 15:38:37 [debug] 28029#0: *629969 realip: “69.0.0.0”
2013/04/16 15:38:37 [debug] 28029#0: *629969 generic phase: 7
2013/04/16 15:38:37 [debug] 28029#0: *629969 generic phase: 8
2013/04/16 15:38:37 [debug] 28029#0: *629969 access phase: 9
2013/04/16 15:38:37 [debug] 28029#0: *629969 access phase: 10
2013/04/16 15:38:37 [debug] 28029#0: *629969 post access phase: 11
2013/04/16 15:38:37 [debug] 28029#0: *629969 try files phase: 12
2013/04/16 15:38:37 [debug] 28029#0: *629969 perl handler
2013/04/16 15:38:37 [debug] 28029#0: *629969 perl variable: “a”
2013/04/16 15:38:37 [debug] 28029#0: *629969 perl variable: “v”
2013/04/16 15:38:37 [debug] 28029#0: *629969 perl variable: “i”
2013/04/16 15:38:37 [debug] 28029#0: *629969 perl variable: “r”
2013/04/16 15:38:37 [debug] 28029#0: *629969 perl variable: “b”
2013/04/16 15:38:37 [debug] 28029#0: *629969 perl variable:
“upstream_http_content_type”
2013/04/16 15:38:37 [debug] 28029#0: *629969 perl variable:
“upstream_status”
2013/04/16 15:38:37 [debug] 28029#0: *629969 call_sv: 1
2013/04/16 15:38:37 [debug] 28029#0: *629969 perl handler done: 1
2013/04/16 15:38:37 [debug] 28029#0: *629969 http finalize request: 1,
“/panel/?” a:1, c:2
2013/04/16 15:38:37 [debug] 28029#0: *629969 http terminate request
count:2
2013/04/16 15:38:37 [debug] 28029#0: *629969 http terminate cleanup
count:2
blk:0
2013/04/16 15:38:37 [debug] 28029#0: *629969 http finalize request: -4,
“/panel/?” a:1, c:2
2013/04/16 15:38:37 [debug] 28029#0: *629969 http request count:2 blk:0
2013/04/16 15:38:37 [debug] 28029#0: *629969 http posted request:
“/panel/?”
2013/04/16 15:38:37 [debug] 28029#0: *629969 http terminate handler
count:1
2013/04/16 15:38:37 [debug] 28029#0: *629969 http request count:1 blk:0
2013/04/16 15:38:37 [debug] 28029#0: *629969 http close request
2013/04/16 15:38:37 [debug] 28029#0: *629969 http log handler
2013/04/16 15:38:37 [debug] 28029#0: *629969 run cleanup:
000000000DA332C8
2013/04/16 15:38:37 [debug] 28029#0: *629969 file cleanup: fd:18
2013/04/16 15:38:37 [debug] 28029#0: *629969 run cleanup:
00000000045C8C60
2013/04/16 15:38:37 [debug] 28029#0: *629969 free: 000000000F2C6570
2013/04/16 15:38:37 [debug] 28029#0: *629969 free: 00000000045C8210,
unused:
0
2013/04/16 15:38:37 [debug] 28029#0: *629969 free: 000000000A2BB580,
unused:
1
2013/04/16 15:38:37 [debug] 28029#0: *629969 free: 000000000DA32A90,
unused:
0
2013/04/16 15:38:37 [debug] 28029#0: *629969 free: 00000000034DEB30,
unused:
2901
2013/04/16 15:38:37 [debug] 28029#0: *629969 close http connection: 16
2013/04/16 15:38:37 [debug] 28029#0: *629969 reusable connection: 0
2013/04/16 15:38:37 [debug] 28029#0: *629969 free: 000000000DCE5A40
2013/04/16 15:38:37 [debug] 28029#0: *629969 free: 00000000038A6F70
2013/04/16 15:38:37 [debug] 28029#0: *629969 free: 00000000028DF7D0,
unused:
8
2013/04/16 15:38:37 [debug] 28029#0: *629969 free: 0000000004433C10,
unused:
115
Posted at Nginx Forum:
Based on your post, I was actually dug a little bit deeper because there
was
nowhere in my Perl I could find that returned 1.
After disabling most of the Perl, I was getting 499 errors which made
sense,
the client was closing the connection. It looks like part of the issue
is
that attached to the location I have a post_action that runs another
perl
method.
This Perl method doesn’t have a return value and, in it’s place, nginx
is
just using 001. When adding a return code to this method, it takes over
the
$status variable in the nginx log file. In general, have the method
return
$r->variable(‘status’) seems to properly emulate exactly what codes the
proxy is actual returning to the browser.
The one exception to this (that I can find) though is if the nginx
return
code was 499. Then I just see 009 in my log files. Is there anything
better
in nginx I can use than $status for getting the status code returned to
the
browser? Alternatively, is there anything I can do so that the log file
doesn’t read the status code from the post_action and instead just reads
it
from the initial location?
Posted at Nginx Forum:
Hello!
On Tue, Apr 16, 2013 at 12:04:32PM -0400, abstein2 wrote:
Sorry for the delay. I do think part of the issue is tied to the load
balancer since that connection is timing out (we set it very low for testing
purposes), but the load balancer terminating the connection doesn’t explain
why nginx is returning a 001 status code, since the connection from the
nginx box to the origin box shouldn’t be affected by that.
[…]
2013/04/16 15:38:37 [debug] 28029#0: *629969 perl variable:
“upstream_http_content_type”
2013/04/16 15:38:37 [debug] 28029#0: *629969 perl variable:
“upstream_status”
2013/04/16 15:38:37 [debug] 28029#0: *629969 call_sv: 1
2013/04/16 15:38:37 [debug] 28029#0: *629969 perl handler done: 1
2013/04/16 15:38:37 [debug] 28029#0: *629969 http finalize request: 1,
“/panel/?” a:1, c:2
As per debug log, the request in question was finalized from a
perl handler with status code 1. Likely just a bug in your perl
code and it’s meant to return 200.
–
Maxim D.
http://nginx.org/en/donation.html