Development guide | nginx documentation
For general purposes, nginx code uses two integer types, ngx_int_t and ngx_uint_t, which are typedefs for intptr_t and uintptr_t respectively. Most functions in nginx return the following codes: NGX_OK — Operation succeeded. NGX_ERROR — Operation failed. NGX_AGAIN — Operation incomplete; call the function again. NGX_DECLINED — Operation rejected, for example, because it is disabled in the configur
Module ngx_http_upstream_module
Defines a group of servers. Servers can listen on different ports. In addition, servers listening on TCP and UNIX-domain sockets can be mixed. Example: upstream backend { server backend1.example.com weight=5; server 127.0.0.1:8080 max_fails=3 fail_timeout=30s; server unix:/tmp/backend3; server backup1.example.com backup; } By default, requests are distributed between the servers using a weighted r
Controlling nginx
In order for nginx to re-read the configuration file, a HUP signal should be sent to the master process. The master process first checks the syntax validity, then tries to apply new configuration, that is, to open log files and new listen sockets. If this fails, it rolls back changes and continues to work with old configuration. If this succeeds, it starts new worker processes, and sends messages
How nginx processes a request
nginx first decides which server should process the request. Let’s start with a simple configuration where all three virtual servers listen on port *:80: server { listen 80; server_name example.org www.example.org; ... } server { listen 80; server_name example.net www.example.net; ... } server { listen 80; server_name example.com www.example.com; ... } In this configuration nginx tests only the re
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
