string …
Defines conditions under which access to a FastCGI server\nis allowed or denied.\nIf all string parameters are not empty\nand not equal to “0” then the access is allowed.\nThe conditions are evaluated each time\nbefore a connection to a FastCGI server is established.\nParameter values can contain variables:
\n\ngeo $upstream_last_addr $allow {\n volatile;\n 10.10.0.0/24 1;\n}\n\nserver {\n listen 127.0.0.1:8080;\n\n location / {\n fastcgi_pass localhost:9000;\n fastcgi_allow_upstream $allow;\n ...\n }\n}\n\n\n" + }, { "name": "fastcgi_bind", "default": "", @@ -2836,6 +2854,24 @@ "description_md": "Makes outgoing connections to a FastCGI server originate\nfrom the specified local IP address with an optional port (1.11.2).\nParameter value can contain variables (1.3.12).\nThe special value `off` (1.3.12) cancels the effect\nof the `fastcgi_bind` directive\ninherited from the previous configuration level, which allows the\nsystem to auto-assign the local IP address and port.\n\nThe `transparent` parameter (1.11.0) allows\noutgoing connections to a FastCGI server originate\nfrom a non-local IP address,\nfor example, from a real IP address of a client:\n```\nfastcgi_bind $remote_addr transparent;\n```\nIn order for this parameter to work,\nit is usually necessary to run nginx worker processes with the\n[superuser](https://nginx.org/en/docs/ngx_core_module.html#user) privileges.\nOn Linux it is not required (1.13.8) as if\nthe `transparent` parameter is specified, worker processes\ninherit the `CAP_NET_RAW` capability from the master process.\nIt is also necessary to configure kernel routing table\nto intercept network traffic from the FastCGI server.", "description_html": "This directive is available as part of our\ncommercial subscription.
\n
Makes outgoing connections to a FastCGI server originate\nfrom the specified local IP address with an optional port (1.11.2).\nParameter value can contain variables (1.3.12).\nThe special value off (1.3.12) cancels the effect\nof the fastcgi_bind directive\ninherited from the previous configuration level, which allows the\nsystem to auto-assign the local IP address and port.
The transparent parameter (1.11.0) allows\noutgoing connections to a FastCGI server originate\nfrom a non-local IP address,\nfor example, from a real IP address of a client:
fastcgi_bind $remote_addr transparent;\nIn order for this parameter to work,\nit is usually necessary to run nginx worker processes with the\nsuperuser privileges.\nOn Linux it is not required (1.13.8) as if\nthe transparent parameter is specified, worker processes\ninherit the CAP_NET_RAW capability from the master process.\nIt is also necessary to configure kernel routing table\nto intercept network traffic from the FastCGI server.
on | off
When enabled, makes the bind operation\nat each connection attempt.
\n\n\n\n" + }, { "name": "fastcgi_buffer_size", "default": "4k|8k", @@ -3383,14 +3419,14 @@ "location" ], "syntax_md": [ - "`error` | `timeout` | `invalid_header` | `http_500` | `http_503` | `http_403` | `http_404` | `http_429` | `non_idempotent` | `off` ..." + "`error` | `timeout` | `denied` | `invalid_header` | `http_500` | `http_503` | `http_403` | `http_404` | `http_429` | `non_idempotent` | `off` ..." ], "syntax_html": [ - "This directive is available as part of our\ncommercial subscription.
\n
error | timeout | invalid_header | http_500 | http_503 | http_403 | http_404 | http_429 | non_idempotent | off …
error | timeout | denied | invalid_header | http_500 | http_503 | http_403 | http_404 | http_429 | non_idempotent | off …
Specifies in which cases a request should be passed to the next server:
\n\nerror
an error occurred while establishing a connection with the\nserver, passing a request to it, or reading the response header;
timeout
a timeout has occurred while establishing a connection with the\nserver, passing a request to it, or reading the response header;
invalid_header
a server returned an empty or invalid response;
http_500
a server returned a response with the code 500;
http_503
a server returned a response with the code 503;
http_403
a server returned a response with the code 403;
http_404
a server returned a response with the code 404;
http_429
a server returned a response with the code 429 (1.11.13);
non_idempotent
normally, requests with a\nnon-idempotent\nmethod\n(POST, LOCK, PATCH)\nare not passed to the next server\nif a request has been sent to an upstream server (1.9.13);\nenabling this option explicitly allows retrying such requests;
off
disables passing a request to the next server.
One should bear in mind that passing a request to the next server is\nonly possible if nothing has been sent to a client yet.\nThat is, if an error or timeout occurs in the middle of the\ntransferring of a response, fixing this is impossible.
\n\nThe directive also defines what is considered an\nunsuccessful attempt of communication with a server.\nThe cases of error, timeout and\ninvalid_header are always considered unsuccessful attempts,\neven if they are not specified in the directive.\nThe cases of http_500, http_503,\nand http_429 are\nconsidered unsuccessful attempts only if they are specified in the directive.\nThe cases of http_403 and http_404\nare never considered unsuccessful attempts.
Passing a request to the next server can be limited by\nthe number of tries\nand by time.
\n" + "description_md": "Specifies in which cases a request should be passed to the next server:\n- `error`\n\n an error occurred while establishing a connection with the\n server, passing a request to it, or reading the response header;\n- `timeout`\n\n a timeout has occurred while establishing a connection with the\n server, passing a request to it, or reading the response header;\n- `denied`\n\n the server [denied](https://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_allow_upstream)\n the connection (1.29.3);\n \n > This parameter is available as part of our\n > [commercial subscription](https://nginx.com/products/).\n- `invalid_header`\n\n a server returned an empty or invalid response;\n- `http_500`\n\n a server returned a response with the code 500;\n- `http_503`\n\n a server returned a response with the code 503;\n- `http_403`\n\n a server returned a response with the code 403;\n- `http_404`\n\n a server returned a response with the code 404;\n- `http_429`\n\n a server returned a response with the code 429 (1.11.13);\n- `non_idempotent`\n\n normally, requests with a\n [non-idempotent](https://datatracker.ietf.org/doc/html/rfc7231#section-4.2.2)\n method\n (`POST`, `LOCK`, `PATCH`)\n are not passed to the next server\n if a request has been sent to an upstream server (1.9.13);\n enabling this option explicitly allows retrying such requests;\n- `off`\n\n disables passing a request to the next server.\n\nOne should bear in mind that passing a request to the next server is\nonly possible if nothing has been sent to a client yet.\nThat is, if an error or timeout occurs in the middle of the\ntransferring of a response, fixing this is impossible.\n\nThe directive also defines what is considered an\n[unsuccessful attempt](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#max_fails) of communication with a server.\nThe cases of `error`, `timeout`,\n`denied` and\n`invalid_header` are always considered unsuccessful attempts,\neven if they are not specified in the directive.\nThe cases of `http_500`, `http_503`,\nand `http_429` are\nconsidered unsuccessful attempts only if they are specified in the directive.\nThe cases of `http_403` and `http_404`\nare never considered unsuccessful attempts.\n\nPassing a request to the next server can be limited by\n[the number of tries](https://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_next_upstream_tries)\nand by [time](https://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_next_upstream_timeout).", + "description_html": "Specifies in which cases a request should be passed to the next server:
\n\nerror
an error occurred while establishing a connection with the\nserver, passing a request to it, or reading the response header;
timeout
a timeout has occurred while establishing a connection with the\nserver, passing a request to it, or reading the response header;
denied
the server denied\nthe connection (1.29.3);
\n\n\n\nThis parameter is available as part of our\ncommercial subscription.
\n
invalid_header
a server returned an empty or invalid response;
http_500
a server returned a response with the code 500;
http_503
a server returned a response with the code 503;
http_403
a server returned a response with the code 403;
http_404
a server returned a response with the code 404;
http_429
a server returned a response with the code 429 (1.11.13);
non_idempotent
normally, requests with a\nnon-idempotent\nmethod\n(POST, LOCK, PATCH)\nare not passed to the next server\nif a request has been sent to an upstream server (1.9.13);\nenabling this option explicitly allows retrying such requests;
off
disables passing a request to the next server.
One should bear in mind that passing a request to the next server is\nonly possible if nothing has been sent to a client yet.\nThat is, if an error or timeout occurs in the middle of the\ntransferring of a response, fixing this is impossible.
\n\nThe directive also defines what is considered an\nunsuccessful attempt of communication with a server.\nThe cases of error, timeout,\ndenied and\ninvalid_header are always considered unsuccessful attempts,\neven if they are not specified in the directive.\nThe cases of http_500, http_503,\nand http_429 are\nconsidered unsuccessful attempts only if they are specified in the directive.\nThe cases of http_403 and http_404\nare never considered unsuccessful attempts.
Passing a request to the next server can be limited by\nthe number of tries\nand by time.
\n" }, { "name": "fastcgi_next_upstream_timeout", @@ -3571,6 +3607,24 @@ "description_md": "Enables or disables buffering of a client request body.\n\nWhen buffering is enabled, the entire request body is\n[read](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_body_buffer_size)\nfrom the client before sending the request to a FastCGI server.\n\nWhen buffering is disabled, the request body is sent to the FastCGI server\nimmediately as it is received.\nIn this case, the request cannot be passed to the\n[next server](https://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_next_upstream)\nif nginx already started sending the request body.", "description_html": "Enables or disables buffering of a client request body.
\n\nWhen buffering is enabled, the entire request body is\nread\nfrom the client before sending the request to a FastCGI server.
\n\nWhen buffering is disabled, the request body is sent to the FastCGI server\nimmediately as it is received.\nIn this case, the request cannot be passed to the\nnext server\nif nginx already started sending the request body.
\n" }, + { + "name": "fastcgi_request_dynamic", + "default": "off", + "contexts": [ + "http", + "server", + "location" + ], + "syntax_md": [ + "`on` | `off`" + ], + "syntax_html": [ + "on | off
Enables or disables creation of a separate request instance\nfor each FastCGI server.\nBy default, a single request is used for all FastCGI servers.\nIf the directive is set to the value “on”,\na separate request instance is created,\nallowing per-server request customization.\nFor example, the server-specific “Host” request header field\ncan be set:
proxy_request_dynamic on;\nproxy_set_header Host $upstream_last_server_name;\n\n\n" + }, { "name": "fastcgi_send_lowat", "default": "0", @@ -3861,6 +3915,24 @@ "id": "/en/docs/http/ngx_http_grpc_module.html", "name": "ngx_http_grpc_module", "directives": [ + { + "name": "grpc_allow_upstream", + "default": "", + "contexts": [ + "http", + "server", + "location" + ], + "syntax_md": [ + "*`address`*" + ], + "syntax_html": [ + "This directive is available as part of our\ncommercial subscription.
\n
address
Defines conditions under which access to a gRPC server\nis allowed or denied.\nIf all string parameters are not empty\nand not equal to “0” then the access is allowed.\nThe conditions are evaluated each time\nbefore a connection to a gRPC server is established.\nParameter values can contain variables:
\n\ngeo $upstream_last_addr $allow {\n volatile;\n 10.10.0.0/24 1;\n}\n\nserver {\n listen 127.0.0.1:8080;\n http2 on;\n\n location / {\n grpc_pass localhost:9000;\n grpc_allow_upstream $allow;\n ...\n }\n}\n\n\n" + }, { "name": "grpc_bind", "default": "", @@ -3879,6 +3951,24 @@ "description_md": "Makes outgoing connections to a gRPC server originate\nfrom the specified local IP address with an optional port.\nParameter value can contain variables.\nThe special value `off` cancels the effect\nof the `grpc_bind` directive\ninherited from the previous configuration level, which allows the\nsystem to auto-assign the local IP address and port.\n\nThe `transparent` parameter allows\noutgoing connections to a gRPC server originate\nfrom a non-local IP address,\nfor example, from a real IP address of a client:\n```\ngrpc_bind $remote_addr transparent;\n```\nIn order for this parameter to work,\nit is usually necessary to run nginx worker processes with the\n[superuser](https://nginx.org/en/docs/ngx_core_module.html#user) privileges.\nOn Linux it is not required as if\nthe `transparent` parameter is specified, worker processes\ninherit the `CAP_NET_RAW` capability from the master process.\nIt is also necessary to configure kernel routing table\nto intercept network traffic from the gRPC server.", "description_html": "This directive is available as part of our\ncommercial subscription.
\n
Makes outgoing connections to a gRPC server originate\nfrom the specified local IP address with an optional port.\nParameter value can contain variables.\nThe special value off cancels the effect\nof the grpc_bind directive\ninherited from the previous configuration level, which allows the\nsystem to auto-assign the local IP address and port.
The transparent parameter allows\noutgoing connections to a gRPC server originate\nfrom a non-local IP address,\nfor example, from a real IP address of a client:
grpc_bind $remote_addr transparent;\nIn order for this parameter to work,\nit is usually necessary to run nginx worker processes with the\nsuperuser privileges.\nOn Linux it is not required as if\nthe transparent parameter is specified, worker processes\ninherit the CAP_NET_RAW capability from the master process.\nIt is also necessary to configure kernel routing table\nto intercept network traffic from the gRPC server.
on | off
When enabled, makes the bind operation\nat each connection attempt.
\n\n\n\n" + }, { "name": "grpc_buffer_size", "default": "4k|8k", @@ -3978,14 +4068,14 @@ "location" ], "syntax_md": [ - "`error` | `timeout` | `invalid_header` | `http_500` | `http_502` | `http_503` | `http_504` | `http_403` | `http_404` | `http_429` | `non_idempotent` | `off` ..." + "`error` | `timeout` | `denied` | `invalid_header` | `http_500` | `http_502` | `http_503` | `http_504` | `http_403` | `http_404` | `http_429` | `non_idempotent` | `off` ..." ], "syntax_html": [ - "This directive is available as part of our\ncommercial subscription.
\n
error | timeout | invalid_header | http_500 | http_502 | http_503 | http_504 | http_403 | http_404 | http_429 | non_idempotent | off …
error | timeout | denied | invalid_header | http_500 | http_502 | http_503 | http_504 | http_403 | http_404 | http_429 | non_idempotent | off …
Specifies in which cases a request should be passed to the next server:
\n\nerror
an error occurred while establishing a connection with the\nserver, passing a request to it, or reading the response header;
timeout
a timeout has occurred while establishing a connection with the\nserver, passing a request to it, or reading the response header;
invalid_header
a server returned an empty or invalid response;
http_500
a server returned a response with the code 500;
http_502
a server returned a response with the code 502;
http_503
a server returned a response with the code 503;
http_504
a server returned a response with the code 504;
http_403
a server returned a response with the code 403;
http_404
a server returned a response with the code 404;
http_429
a server returned a response with the code 429;
non_idempotent
normally, requests with a\nnon-idempotent\nmethod\n(POST, LOCK, PATCH)\nare not passed to the next server\nif a request has been sent to an upstream server;\nenabling this option explicitly allows retrying such requests;
off
disables passing a request to the next server.
One should bear in mind that passing a request to the next server is\nonly possible if nothing has been sent to a client yet.\nThat is, if an error or timeout occurs in the middle of the\ntransferring of a response, fixing this is impossible.
\n\nThe directive also defines what is considered an\nunsuccessful attempt of communication with a server.\nThe cases of error, timeout and\ninvalid_header are always considered unsuccessful attempts,\neven if they are not specified in the directive.\nThe cases of http_500, http_502,\nhttp_503, http_504,\nand http_429 are\nconsidered unsuccessful attempts only if they are specified in the directive.\nThe cases of http_403 and http_404\nare never considered unsuccessful attempts.
Passing a request to the next server can be limited by\nthe number of tries\nand by time.
\n" + "description_md": "Specifies in which cases a request should be passed to the next server:\n- `error`\n\n an error occurred while establishing a connection with the\n server, passing a request to it, or reading the response header;\n- `timeout`\n\n a timeout has occurred while establishing a connection with the\n server, passing a request to it, or reading the response header;\n- `denied`\n\n the server [denied](https://nginx.org/en/docs/http/ngx_http_grpc_module.html#grpc_allow_upstream)\n the connection (1.29.3);\n \n > This parameter is available as part of our\n > [commercial subscription](https://nginx.com/products/).\n- `invalid_header`\n\n a server returned an empty or invalid response;\n- `http_500`\n\n a server returned a response with the code 500;\n- `http_502`\n\n a server returned a response with the code 502;\n- `http_503`\n\n a server returned a response with the code 503;\n- `http_504`\n\n a server returned a response with the code 504;\n- `http_403`\n\n a server returned a response with the code 403;\n- `http_404`\n\n a server returned a response with the code 404;\n- `http_429`\n\n a server returned a response with the code 429;\n- `non_idempotent`\n\n normally, requests with a\n [non-idempotent](https://datatracker.ietf.org/doc/html/rfc7231#section-4.2.2)\n method\n (`POST`, `LOCK`, `PATCH`)\n are not passed to the next server\n if a request has been sent to an upstream server;\n enabling this option explicitly allows retrying such requests;\n- `off`\n\n disables passing a request to the next server.\n\nOne should bear in mind that passing a request to the next server is\nonly possible if nothing has been sent to a client yet.\nThat is, if an error or timeout occurs in the middle of the\ntransferring of a response, fixing this is impossible.\n\nThe directive also defines what is considered an\n[unsuccessful attempt](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#max_fails) of communication with a server.\nThe cases of `error`, `timeout`,\n`denied` and\n`invalid_header` are always considered unsuccessful attempts,\neven if they are not specified in the directive.\nThe cases of `http_500`, `http_502`,\n`http_503`, `http_504`,\nand `http_429` are\nconsidered unsuccessful attempts only if they are specified in the directive.\nThe cases of `http_403` and `http_404`\nare never considered unsuccessful attempts.\n\nPassing a request to the next server can be limited by\n[the number of tries](https://nginx.org/en/docs/http/ngx_http_grpc_module.html#grpc_next_upstream_tries)\nand by [time](https://nginx.org/en/docs/http/ngx_http_grpc_module.html#grpc_next_upstream_timeout).", + "description_html": "Specifies in which cases a request should be passed to the next server:
\n\nerror
an error occurred while establishing a connection with the\nserver, passing a request to it, or reading the response header;
timeout
a timeout has occurred while establishing a connection with the\nserver, passing a request to it, or reading the response header;
denied
the server denied\nthe connection (1.29.3);
\n\n\n\nThis parameter is available as part of our\ncommercial subscription.
\n
invalid_header
a server returned an empty or invalid response;
http_500
a server returned a response with the code 500;
http_502
a server returned a response with the code 502;
http_503
a server returned a response with the code 503;
http_504
a server returned a response with the code 504;
http_403
a server returned a response with the code 403;
http_404
a server returned a response with the code 404;
http_429
a server returned a response with the code 429;
non_idempotent
normally, requests with a\nnon-idempotent\nmethod\n(POST, LOCK, PATCH)\nare not passed to the next server\nif a request has been sent to an upstream server;\nenabling this option explicitly allows retrying such requests;
off
disables passing a request to the next server.
One should bear in mind that passing a request to the next server is\nonly possible if nothing has been sent to a client yet.\nThat is, if an error or timeout occurs in the middle of the\ntransferring of a response, fixing this is impossible.
\n\nThe directive also defines what is considered an\nunsuccessful attempt of communication with a server.\nThe cases of error, timeout,\ndenied and\ninvalid_header are always considered unsuccessful attempts,\neven if they are not specified in the directive.\nThe cases of http_500, http_502,\nhttp_503, http_504,\nand http_429 are\nconsidered unsuccessful attempts only if they are specified in the directive.\nThe cases of http_403 and http_404\nare never considered unsuccessful attempts.
Passing a request to the next server can be limited by\nthe number of tries\nand by time.
\n" }, { "name": "grpc_next_upstream_timeout", @@ -4076,6 +4166,24 @@ "description_md": "Defines a timeout for reading a response from the gRPC server.\nThe timeout is set only between two successive read operations,\nnot for the transmission of the whole response.\nIf the gRPC server does not transmit anything within this time,\nthe connection is closed.", "description_html": "Defines a timeout for reading a response from the gRPC server.\nThe timeout is set only between two successive read operations,\nnot for the transmission of the whole response.\nIf the gRPC server does not transmit anything within this time,\nthe connection is closed.
\n" }, + { + "name": "grpc_request_dynamic", + "default": "off", + "contexts": [ + "http", + "server", + "location" + ], + "syntax_md": [ + "`on` | `off`" + ], + "syntax_html": [ + "on | off
Enables or disables creation of a separate request instance\nfor each gRPC server.\nBy default, a single request is used for all gRPC servers.\nIf the directive is set to the value “on”,\na separate request instance is created,\nallowing per-server request customization.\nFor example, the server-specific “Host” request header field\ncan be set:
proxy_request_dynamic on;\nproxy_set_header Host $upstream_last_server_name;\n\n\n" + }, { "name": "grpc_send_timeout", "default": "60s", @@ -5894,6 +6002,24 @@ "id": "/en/docs/http/ngx_http_memcached_module.html", "name": "ngx_http_memcached_module", "directives": [ + { + "name": "memcached_allow_upstream", + "default": "", + "contexts": [ + "http", + "server", + "location" + ], + "syntax_md": [ + "*`string`* ..." + ], + "syntax_html": [ + "This directive is available as part of our\ncommercial subscription.
\n
string …
Defines conditions under which access to a memcached server\nis allowed or denied.\nIf all string parameters are not empty\nand not equal to “0” then the access is allowed.\nThe conditions are evaluated each time\nbefore a connection to a memcached server is established.\nParameter values can contain variables:
\n\ngeo $upstream_last_addr $allow {\n volatile;\n 10.10.0.0/24 1;\n}\n\nserver {\n listen 127.0.0.1:8080;\n\n location / {\n memcached_pass host:11211;\n memcached_allow_upstream $allow;\n ...\n }\n}\n\n\n" + }, { "name": "memcached_bind", "default": "", @@ -5912,6 +6038,24 @@ "description_md": "Makes outgoing connections to a memcached server originate\nfrom the specified local IP address with an optional port (1.11.2).\nParameter value can contain variables (1.3.12).\nThe special value `off` (1.3.12) cancels the effect\nof the `memcached_bind` directive\ninherited from the previous configuration level, which allows the\nsystem to auto-assign the local IP address and port.\n\nThe `transparent` parameter (1.11.0) allows\noutgoing connections to a memcached server originate\nfrom a non-local IP address,\nfor example, from a real IP address of a client:\n```\nmemcached_bind $remote_addr transparent;\n```\nIn order for this parameter to work,\nit is usually necessary to run nginx worker processes with the\n[superuser](https://nginx.org/en/docs/ngx_core_module.html#user) privileges.\nOn Linux it is not required (1.13.8) as if\nthe `transparent` parameter is specified, worker processes\ninherit the `CAP_NET_RAW` capability from the master process.\nIt is also necessary to configure kernel routing table\nto intercept network traffic from the memcached server.", "description_html": "This directive is available as part of our\ncommercial subscription.
\n
Makes outgoing connections to a memcached server originate\nfrom the specified local IP address with an optional port (1.11.2).\nParameter value can contain variables (1.3.12).\nThe special value off (1.3.12) cancels the effect\nof the memcached_bind directive\ninherited from the previous configuration level, which allows the\nsystem to auto-assign the local IP address and port.
The transparent parameter (1.11.0) allows\noutgoing connections to a memcached server originate\nfrom a non-local IP address,\nfor example, from a real IP address of a client:
memcached_bind $remote_addr transparent;\nIn order for this parameter to work,\nit is usually necessary to run nginx worker processes with the\nsuperuser privileges.\nOn Linux it is not required (1.13.8) as if\nthe transparent parameter is specified, worker processes\ninherit the CAP_NET_RAW capability from the master process.\nIt is also necessary to configure kernel routing table\nto intercept network traffic from the memcached server.
on | off
When enabled, makes the bind operation\nat each connection attempt.
\n\n\n\n" + }, { "name": "memcached_buffer_size", "default": "4k|8k", @@ -5975,14 +6119,14 @@ "location" ], "syntax_md": [ - "`error` | `timeout` | `invalid_response` | `not_found` | `off` ..." + "`error` | `timeout` | `denied` | `invalid_response` | `not_found` | `off` ..." ], "syntax_html": [ - "This directive is available as part of our\ncommercial subscription.
\n
error | timeout | invalid_response | not_found | off …
error | timeout | denied | invalid_response | not_found | off …
Specifies in which cases a request should be passed to the next server:
\n\nerror
an error occurred while establishing a connection with the\nserver, passing a request to it, or reading the response header;
timeout
a timeout has occurred while establishing a connection with the\nserver, passing a request to it, or reading the response header;
invalid_response
a server returned an empty or invalid response;
not_found
a response was not found on the server;
off
disables passing a request to the next server.
One should bear in mind that passing a request to the next server is\nonly possible if nothing has been sent to a client yet.\nThat is, if an error or timeout occurs in the middle of the\ntransferring of a response, fixing this is impossible.
\n\nThe directive also defines what is considered an\nunsuccessful attempt of communication with a server.\nThe cases of error, timeout and\ninvalid_response are always considered unsuccessful attempts,\neven if they are not specified in the directive.\nThe case of not_found\nis never considered an unsuccessful attempt.
Passing a request to the next server can be limited by\nthe number of tries\nand by time.
\n" + "description_md": "Specifies in which cases a request should be passed to the next server:\n- `error`\n\n an error occurred while establishing a connection with the\n server, passing a request to it, or reading the response header;\n- `timeout`\n\n a timeout has occurred while establishing a connection with the\n server, passing a request to it, or reading the response header;\n- `denied`\n\n the server [denied](https://nginx.org/en/docs/http/ngx_http_memcached_module.html#memcached_allow_upstream)\n the connection (1.29.3);\n \n > This parameter is available as part of our\n > [commercial subscription](https://nginx.com/products/).\n- `invalid_response`\n\n a server returned an empty or invalid response;\n- `not_found`\n\n a response was not found on the server;\n- `off`\n\n disables passing a request to the next server.\n\nOne should bear in mind that passing a request to the next server is\nonly possible if nothing has been sent to a client yet.\nThat is, if an error or timeout occurs in the middle of the\ntransferring of a response, fixing this is impossible.\n\nThe directive also defines what is considered an\n[unsuccessful attempt](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#max_fails) of communication with a server.\nThe cases of `error`, `timeout`,\n`denied` and\n`invalid_response` are always considered unsuccessful attempts,\neven if they are not specified in the directive.\nThe case of `not_found`\nis never considered an unsuccessful attempt.\n\nPassing a request to the next server can be limited by\n[the number of tries](https://nginx.org/en/docs/http/ngx_http_memcached_module.html#memcached_next_upstream_tries)\nand by [time](https://nginx.org/en/docs/http/ngx_http_memcached_module.html#memcached_next_upstream_timeout).", + "description_html": "Specifies in which cases a request should be passed to the next server:
\n\nerror
an error occurred while establishing a connection with the\nserver, passing a request to it, or reading the response header;
timeout
a timeout has occurred while establishing a connection with the\nserver, passing a request to it, or reading the response header;
denied
the server denied\nthe connection (1.29.3);
\n\n\n\nThis parameter is available as part of our\ncommercial subscription.
\n
invalid_response
a server returned an empty or invalid response;
not_found
a response was not found on the server;
off
disables passing a request to the next server.
One should bear in mind that passing a request to the next server is\nonly possible if nothing has been sent to a client yet.\nThat is, if an error or timeout occurs in the middle of the\ntransferring of a response, fixing this is impossible.
\n\nThe directive also defines what is considered an\nunsuccessful attempt of communication with a server.\nThe cases of error, timeout,\ndenied and\ninvalid_response are always considered unsuccessful attempts,\neven if they are not specified in the directive.\nThe case of not_found\nis never considered an unsuccessful attempt.
Passing a request to the next server can be limited by\nthe number of tries\nand by time.
\n" }, { "name": "memcached_next_upstream_timeout", @@ -6254,6 +6398,28 @@ } ] }, + { + "id": "/en/docs/http/ngx_http_num_map_module.html", + "name": "ngx_http_num_map_module", + "directives": [ + { + "name": "num_map", + "default": "", + "contexts": [ + "http" + ], + "syntax_md": [ + "[*`$number`*] *`$variable`* `{...}`" + ], + "syntax_html": [ + "[$number] $variable {...}
Describes how the values of the specified variable depend on numeric values\nor numeric value ranges.
\n\n\n\n\nSince variables are evaluated only when used, the mere existence\nof even a large number of declared “
\nnum_map” variables\ndoes not cause any extra costs for request processing.
Parameters inside the num_map block specify a mapping\nbetween source and resulting values.
Source values are specified as numbers or as numeric ranges.
\n\nThe following special parameters are also supported:
\n\ndefault
sets the resulting value if the source value matches none\nof the specified variants.\nWhen default is not specified, the default\nresulting value will be an empty string.
include
includes a file with values.\nThere can be several inclusions.
volatile
indicates that the variable is not cacheable.
string
Specifies a secret value\nused to authenticate the Relying Party with the OpenID Provider.
\n" + "description_md": "Specifies a secret value\nused to authenticate the Relying Party with the OpenID Provider.\nThe supported\n[authentication methods](https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication) are\n`client_secret_basic` and\n`client_secret_post` (1.29.3).\nThe method is selected based on the OpenID Provider metadata\nwith a preference to `client_secret_basic`.", + "description_html": "Specifies a secret value\nused to authenticate the Relying Party with the OpenID Provider.\nThe supported\nauthentication methods are\nclient_secret_basic and\nclient_secret_post (1.29.3).\nThe method is selected based on the OpenID Provider metadata\nwith a preference to client_secret_basic.
Sets additional query arguments for the\nauthentication request URL.
\n\nextra_auth_args "display=page&prompt=login";\nuri
Defines the URI path for triggering\nfront-channel logout.\nFor the logout request to be associated with a user session,\nit must either include the module session cookie or provide\nboth the “iss” and “sid” arguments.\nIt is recommended to configure the OpenID Provider to set the\n“iss” and “sid” arguments\nwhen invoking this endpoint.
on | off
Explicitly enables or disables PKCE.\nBy default, PKCE is automatically enabled\nbased on OpenID Provider metadata.
\n" + }, { "name": "redirect_uri", "default": "/oidc_callback", @@ -6647,6 +6845,24 @@ "id": "/en/docs/http/ngx_http_proxy_module.html", "name": "ngx_http_proxy_module", "directives": [ + { + "name": "proxy_allow_upstream", + "default": "", + "contexts": [ + "http", + "server", + "location" + ], + "syntax_md": [ + "*`string`* ..." + ], + "syntax_html": [ + "string …
Defines conditions under which access to a proxied server\nis allowed or denied.\nIf all string parameters are not empty\nand not equal to “0” then the access is allowed.\nThe conditions are evaluated each time\nbefore a connection to a proxied server is established.\nParameter values can contain variables:
\n\ngeo $upstream_last_addr $allow {\n volatile;\n 10.10.0.0/24 1;\n}\n\nserver {\n listen 127.0.0.1:8080;\n\n location / {\n proxy_pass localhost:8000;\n proxy_allow_upstream $allow;\n ...\n }\n}\n\n\n" + }, { "name": "proxy_bind", "default": "", @@ -6665,6 +6881,24 @@ "description_md": "Makes outgoing connections to a proxied server originate\nfrom the specified local IP address with an optional port (1.11.2).\nParameter value can contain variables (1.3.12).\nThe special value `off` (1.3.12) cancels the effect\nof the `proxy_bind` directive\ninherited from the previous configuration level, which allows the\nsystem to auto-assign the local IP address and port.\n\nThe `transparent` parameter (1.11.0) allows\noutgoing connections to a proxied server originate\nfrom a non-local IP address,\nfor example, from a real IP address of a client:\n```\nproxy_bind $remote_addr transparent;\n```\nIn order for this parameter to work,\nit is usually necessary to run nginx worker processes with the\n[superuser](https://nginx.org/en/docs/ngx_core_module.html#user) privileges.\nOn Linux it is not required (1.13.8) as if\nthe `transparent` parameter is specified, worker processes\ninherit the `CAP_NET_RAW` capability from the master process.\nIt is also necessary to configure kernel routing table\nto intercept network traffic from the proxied server.", "description_html": "This directive is available as part of our\ncommercial subscription.
\n
Makes outgoing connections to a proxied server originate\nfrom the specified local IP address with an optional port (1.11.2).\nParameter value can contain variables (1.3.12).\nThe special value off (1.3.12) cancels the effect\nof the proxy_bind directive\ninherited from the previous configuration level, which allows the\nsystem to auto-assign the local IP address and port.
The transparent parameter (1.11.0) allows\noutgoing connections to a proxied server originate\nfrom a non-local IP address,\nfor example, from a real IP address of a client:
proxy_bind $remote_addr transparent;\nIn order for this parameter to work,\nit is usually necessary to run nginx worker processes with the\nsuperuser privileges.\nOn Linux it is not required (1.13.8) as if\nthe transparent parameter is specified, worker processes\ninherit the CAP_NET_RAW capability from the master process.\nIt is also necessary to configure kernel routing table\nto intercept network traffic from the proxied server.
on | off
When enabled, makes the bind operation\nat each connection attempt.
\n\n\n\n" + }, { "name": "proxy_buffer_size", "default": "4k|8k", @@ -7306,14 +7540,14 @@ "location" ], "syntax_md": [ - "`error` | `timeout` | `invalid_header` | `http_500` | `http_502` | `http_503` | `http_504` | `http_403` | `http_404` | `http_429` | `non_idempotent` | `off` ..." + "`error` | `timeout` | `denied` | `invalid_header` | `http_500` | `http_502` | `http_503` | `http_504` | `http_403` | `http_404` | `http_429` | `non_idempotent` | `off` ..." ], "syntax_html": [ - "This directive is available as part of our\ncommercial subscription.
\n
error | timeout | invalid_header | http_500 | http_502 | http_503 | http_504 | http_403 | http_404 | http_429 | non_idempotent | off …
error | timeout | denied | invalid_header | http_500 | http_502 | http_503 | http_504 | http_403 | http_404 | http_429 | non_idempotent | off …
Specifies in which cases a request should be passed to the next server:
\n\nerror
an error occurred while establishing a connection with the\nserver, passing a request to it, or reading the response header;
timeout
a timeout has occurred while establishing a connection with the\nserver, passing a request to it, or reading the response header;
invalid_header
a server returned an empty or invalid response;
http_500
a server returned a response with the code 500;
http_502
a server returned a response with the code 502;
http_503
a server returned a response with the code 503;
http_504
a server returned a response with the code 504;
http_403
a server returned a response with the code 403;
http_404
a server returned a response with the code 404;
http_429
a server returned a response with the code 429 (1.11.13);
non_idempotent
normally, requests with a\nnon-idempotent\nmethod\n(POST, LOCK, PATCH)\nare not passed to the next server\nif a request has been sent to an upstream server (1.9.13);\nenabling this option explicitly allows retrying such requests;
off
disables passing a request to the next server.
One should bear in mind that passing a request to the next server is\nonly possible if nothing has been sent to a client yet.\nThat is, if an error or timeout occurs in the middle of the\ntransferring of a response, fixing this is impossible.
\n\nThe directive also defines what is considered an\nunsuccessful attempt of communication with a server.\nThe cases of error, timeout and\ninvalid_header are always considered unsuccessful attempts,\neven if they are not specified in the directive.\nThe cases of http_500, http_502,\nhttp_503, http_504,\nand http_429 are\nconsidered unsuccessful attempts only if they are specified in the directive.\nThe cases of http_403 and http_404\nare never considered unsuccessful attempts.
Passing a request to the next server can be limited by\nthe number of tries\nand by time.
\n" + "description_md": "Specifies in which cases a request should be passed to the next server:\n- `error`\n\n an error occurred while establishing a connection with the\n server, passing a request to it, or reading the response header;\n- `timeout`\n\n a timeout has occurred while establishing a connection with the\n server, passing a request to it, or reading the response header;\n- `denied`\n\n the server [denied](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_allow_upstream)\n the connection (1.29.3);\n \n > This parameter is available as part of our\n > [commercial subscription](https://nginx.com/products/).\n- `invalid_header`\n\n a server returned an empty or invalid response;\n- `http_500`\n\n a server returned a response with the code 500;\n- `http_502`\n\n a server returned a response with the code 502;\n- `http_503`\n\n a server returned a response with the code 503;\n- `http_504`\n\n a server returned a response with the code 504;\n- `http_403`\n\n a server returned a response with the code 403;\n- `http_404`\n\n a server returned a response with the code 404;\n- `http_429`\n\n a server returned a response with the code 429 (1.11.13);\n- `non_idempotent`\n\n normally, requests with a\n [non-idempotent](https://datatracker.ietf.org/doc/html/rfc7231#section-4.2.2)\n method\n (`POST`, `LOCK`, `PATCH`)\n are not passed to the next server\n if a request has been sent to an upstream server (1.9.13);\n enabling this option explicitly allows retrying such requests;\n- `off`\n\n disables passing a request to the next server.\n\nOne should bear in mind that passing a request to the next server is\nonly possible if nothing has been sent to a client yet.\nThat is, if an error or timeout occurs in the middle of the\ntransferring of a response, fixing this is impossible.\n\nThe directive also defines what is considered an\n[unsuccessful attempt](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#max_fails) of communication with a server.\nThe cases of `error`, `timeout`,\n`denied` and\n`invalid_header` are always considered unsuccessful attempts,\neven if they are not specified in the directive.\nThe cases of `http_500`, `http_502`,\n`http_503`, `http_504`,\nand `http_429` are\nconsidered unsuccessful attempts only if they are specified in the directive.\nThe cases of `http_403` and `http_404`\nare never considered unsuccessful attempts.\n\nPassing a request to the next server can be limited by\n[the number of tries](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_next_upstream_tries)\nand by [time](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_next_upstream_timeout).", + "description_html": "Specifies in which cases a request should be passed to the next server:
\n\nerror
an error occurred while establishing a connection with the\nserver, passing a request to it, or reading the response header;
timeout
a timeout has occurred while establishing a connection with the\nserver, passing a request to it, or reading the response header;
denied
the server denied\nthe connection (1.29.3);
\n\n\n\nThis parameter is available as part of our\ncommercial subscription.
\n
invalid_header
a server returned an empty or invalid response;
http_500
a server returned a response with the code 500;
http_502
a server returned a response with the code 502;
http_503
a server returned a response with the code 503;
http_504
a server returned a response with the code 504;
http_403
a server returned a response with the code 403;
http_404
a server returned a response with the code 404;
http_429
a server returned a response with the code 429 (1.11.13);
non_idempotent
normally, requests with a\nnon-idempotent\nmethod\n(POST, LOCK, PATCH)\nare not passed to the next server\nif a request has been sent to an upstream server (1.9.13);\nenabling this option explicitly allows retrying such requests;
off
disables passing a request to the next server.
One should bear in mind that passing a request to the next server is\nonly possible if nothing has been sent to a client yet.\nThat is, if an error or timeout occurs in the middle of the\ntransferring of a response, fixing this is impossible.
\n\nThe directive also defines what is considered an\nunsuccessful attempt of communication with a server.\nThe cases of error, timeout,\ndenied and\ninvalid_header are always considered unsuccessful attempts,\neven if they are not specified in the directive.\nThe cases of http_500, http_502,\nhttp_503, http_504,\nand http_429 are\nconsidered unsuccessful attempts only if they are specified in the directive.\nThe cases of http_403 and http_404\nare never considered unsuccessful attempts.
Passing a request to the next server can be limited by\nthe number of tries\nand by time.
\n" }, { "name": "proxy_next_upstream_timeout", @@ -7517,6 +7751,24 @@ "description_md": "Enables or disables buffering of a client request body.\n\nWhen buffering is enabled, the entire request body is\n[read](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_body_buffer_size)\nfrom the client before sending the request to a proxied server.\n\nWhen buffering is disabled, the request body is sent to the proxied server\nimmediately as it is received.\nIn this case, the request cannot be passed to the\n[next server](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_next_upstream)\nif nginx already started sending the request body.\n\nWhen HTTP/1.1 chunked transfer encoding is used\nto send the original request body,\nthe request body will be buffered regardless of the directive value unless\nHTTP/1.1 is [enabled](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_http_version) for proxying.", "description_html": "Enables or disables buffering of a client request body.
\n\nWhen buffering is enabled, the entire request body is\nread\nfrom the client before sending the request to a proxied server.
\n\nWhen buffering is disabled, the request body is sent to the proxied server\nimmediately as it is received.\nIn this case, the request cannot be passed to the\nnext server\nif nginx already started sending the request body.
\n\nWhen HTTP/1.1 chunked transfer encoding is used\nto send the original request body,\nthe request body will be buffered regardless of the directive value unless\nHTTP/1.1 is enabled for proxying.
\n" }, + { + "name": "proxy_request_dynamic", + "default": "off", + "contexts": [ + "http", + "server", + "location" + ], + "syntax_md": [ + "`on` | `off`" + ], + "syntax_html": [ + "on | off
Enables or disables creation of a separate request instance\nfor each proxied server.\nBy default, a single request is used for all proxied servers.\nIf the directive is set to the value “on”,\na separate request instance is created,\nallowing per-server request customization.\nFor example, the server-specific “Host” request header field\ncan be set:
proxy_request_dynamic on;\nproxy_set_header Host $upstream_last_server_name;\n\n\n" + }, { "name": "proxy_send_lowat", "default": "0", @@ -8269,6 +8521,24 @@ "id": "/en/docs/http/ngx_http_scgi_module.html", "name": "ngx_http_scgi_module", "directives": [ + { + "name": "scgi_allow_upstream", + "default": "", + "contexts": [ + "http", + "server", + "location" + ], + "syntax_md": [ + "*`string`* ..." + ], + "syntax_html": [ + "This directive is available as part of our\ncommercial subscription.
\n
string …
Defines conditions under which access to an SCGI server\nis allowed or denied.\nIf all string parameters are not empty\nand not equal to “0” then the access is allowed.\nThe conditions are evaluated each time\nbefore a connection to an SCGI server is established.\nParameter values can contain variables:
\n\ngeo $upstream_last_addr $allow {\n volatile;\n 10.10.0.0/24 1;\n}\n\nserver {\n listen 127.0.0.1:8080;\n\n location / {\n scgi_pass localhost:9000;\n scgi_allow_upstream $allow;\n ...\n }\n}\n\n\n" + }, { "name": "scgi_bind", "default": "", @@ -8287,6 +8557,24 @@ "description_md": "Makes outgoing connections to an SCGI server originate\nfrom the specified local IP address with an optional port (1.11.2).\nParameter value can contain variables (1.3.12).\nThe special value `off` (1.3.12) cancels the effect\nof the `scgi_bind` directive\ninherited from the previous configuration level, which allows the\nsystem to auto-assign the local IP address and port.\n\nThe `transparent` parameter (1.11.0) allows\noutgoing connections to an SCGI server originate\nfrom a non-local IP address,\nfor example, from a real IP address of a client:\n```\nscgi_bind $remote_addr transparent;\n```\nIn order for this parameter to work,\nit is usually necessary to run nginx worker processes with the\n[superuser](https://nginx.org/en/docs/ngx_core_module.html#user) privileges.\nOn Linux it is not required (1.13.8) as if\nthe `transparent` parameter is specified, worker processes\ninherit the `CAP_NET_RAW` capability from the master process.\nIt is also necessary to configure kernel routing table\nto intercept network traffic from the SCGI server.", "description_html": "This directive is available as part of our\ncommercial subscription.
\n
Makes outgoing connections to an SCGI server originate\nfrom the specified local IP address with an optional port (1.11.2).\nParameter value can contain variables (1.3.12).\nThe special value off (1.3.12) cancels the effect\nof the scgi_bind directive\ninherited from the previous configuration level, which allows the\nsystem to auto-assign the local IP address and port.
The transparent parameter (1.11.0) allows\noutgoing connections to an SCGI server originate\nfrom a non-local IP address,\nfor example, from a real IP address of a client:
scgi_bind $remote_addr transparent;\nIn order for this parameter to work,\nit is usually necessary to run nginx worker processes with the\nsuperuser privileges.\nOn Linux it is not required (1.13.8) as if\nthe transparent parameter is specified, worker processes\ninherit the CAP_NET_RAW capability from the master process.\nIt is also necessary to configure kernel routing table\nto intercept network traffic from the SCGI server.
on | off
When enabled, makes the bind operation\nat each connection attempt.
\n\n\n\n" + }, { "name": "scgi_buffer_size", "default": "4k|8k", @@ -8780,14 +9068,14 @@ "location" ], "syntax_md": [ - "`error` | `timeout` | `invalid_header` | `http_500` | `http_503` | `http_403` | `http_404` | `http_429` | `non_idempotent` | `off` ..." + "`error` | `timeout` | `denied` | `invalid_header` | `http_500` | `http_503` | `http_403` | `http_404` | `http_429` | `non_idempotent` | `off` ..." ], "syntax_html": [ - "This directive is available as part of our\ncommercial subscription.
\n
error | timeout | invalid_header | http_500 | http_503 | http_403 | http_404 | http_429 | non_idempotent | off …
error | timeout | denied | invalid_header | http_500 | http_503 | http_403 | http_404 | http_429 | non_idempotent | off …
Specifies in which cases a request should be passed to the next server:
\n\nerror
an error occurred while establishing a connection with the\nserver, passing a request to it, or reading the response header;
timeout
a timeout has occurred while establishing a connection with the\nserver, passing a request to it, or reading the response header;
invalid_header
a server returned an empty or invalid response;
http_500
a server returned a response with the code 500;
http_503
a server returned a response with the code 503;
http_403
a server returned a response with the code 403;
http_404
a server returned a response with the code 404;
http_429
a server returned a response with the code 429 (1.11.13);
non_idempotent
normally, requests with a\nnon-idempotent\nmethod\n(POST, LOCK, PATCH)\nare not passed to the next server\nif a request has been sent to an upstream server (1.9.13);\nenabling this option explicitly allows retrying such requests;
off
disables passing a request to the next server.
One should bear in mind that passing a request to the next server is\nonly possible if nothing has been sent to a client yet.\nThat is, if an error or timeout occurs in the middle of the\ntransferring of a response, fixing this is impossible.
\n\nThe directive also defines what is considered an\nunsuccessful attempt of communication with a server.\nThe cases of error, timeout and\ninvalid_header are always considered unsuccessful attempts,\neven if they are not specified in the directive.\nThe cases of http_500, http_503,\nand http_429 are\nconsidered unsuccessful attempts only if they are specified in the directive.\nThe cases of http_403 and http_404\nare never considered unsuccessful attempts.
Passing a request to the next server can be limited by\nthe number of tries\nand by time.
\n" + "description_md": "Specifies in which cases a request should be passed to the next server:\n- `error`\n\n an error occurred while establishing a connection with the\n server, passing a request to it, or reading the response header;\n- `timeout`\n\n a timeout has occurred while establishing a connection with the\n server, passing a request to it, or reading the response header;\n- `denied`\n\n the server [denied](https://nginx.org/en/docs/http/ngx_http_scgi_module.html#scgi_allow_upstream)\n the connection (1.29.3);\n \n > This parameter is available as part of our\n > [commercial subscription](https://nginx.com/products/).\n- `invalid_header`\n\n a server returned an empty or invalid response;\n- `http_500`\n\n a server returned a response with the code 500;\n- `http_503`\n\n a server returned a response with the code 503;\n- `http_403`\n\n a server returned a response with the code 403;\n- `http_404`\n\n a server returned a response with the code 404;\n- `http_429`\n\n a server returned a response with the code 429 (1.11.13);\n- `non_idempotent`\n\n normally, requests with a\n [non-idempotent](https://datatracker.ietf.org/doc/html/rfc7231#section-4.2.2)\n method\n (`POST`, `LOCK`, `PATCH`)\n are not passed to the next server\n if a request has been sent to an upstream server (1.9.13);\n enabling this option explicitly allows retrying such requests;\n- `off`\n\n disables passing a request to the next server.\n\nOne should bear in mind that passing a request to the next server is\nonly possible if nothing has been sent to a client yet.\nThat is, if an error or timeout occurs in the middle of the\ntransferring of a response, fixing this is impossible.\n\nThe directive also defines what is considered an\n[unsuccessful attempt](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#max_fails) of communication with a server.\nThe cases of `error`, `timeout`,\n`denied` and\n`invalid_header` are always considered unsuccessful attempts,\neven if they are not specified in the directive.\nThe cases of `http_500`, `http_503`,\nand `http_429` are\nconsidered unsuccessful attempts only if they are specified in the directive.\nThe cases of `http_403` and `http_404`\nare never considered unsuccessful attempts.\n\nPassing a request to the next server can be limited by\n[the number of tries](https://nginx.org/en/docs/http/ngx_http_scgi_module.html#scgi_next_upstream_tries)\nand by [time](https://nginx.org/en/docs/http/ngx_http_scgi_module.html#scgi_next_upstream_timeout).", + "description_html": "Specifies in which cases a request should be passed to the next server:
\n\nerror
an error occurred while establishing a connection with the\nserver, passing a request to it, or reading the response header;
timeout
a timeout has occurred while establishing a connection with the\nserver, passing a request to it, or reading the response header;
denied
the server denied\nthe connection (1.29.3);
\n\n\n\nThis parameter is available as part of our\ncommercial subscription.
\n
invalid_header
a server returned an empty or invalid response;
http_500
a server returned a response with the code 500;
http_503
a server returned a response with the code 503;
http_403
a server returned a response with the code 403;
http_404
a server returned a response with the code 404;
http_429
a server returned a response with the code 429 (1.11.13);
non_idempotent
normally, requests with a\nnon-idempotent\nmethod\n(POST, LOCK, PATCH)\nare not passed to the next server\nif a request has been sent to an upstream server (1.9.13);\nenabling this option explicitly allows retrying such requests;
off
disables passing a request to the next server.
One should bear in mind that passing a request to the next server is\nonly possible if nothing has been sent to a client yet.\nThat is, if an error or timeout occurs in the middle of the\ntransferring of a response, fixing this is impossible.
\n\nThe directive also defines what is considered an\nunsuccessful attempt of communication with a server.\nThe cases of error, timeout,\ndenied and\ninvalid_header are always considered unsuccessful attempts,\neven if they are not specified in the directive.\nThe cases of http_500, http_503,\nand http_429 are\nconsidered unsuccessful attempts only if they are specified in the directive.\nThe cases of http_403 and http_404\nare never considered unsuccessful attempts.
Passing a request to the next server can be limited by\nthe number of tries\nand by time.
\n" }, { "name": "scgi_next_upstream_timeout", @@ -8968,6 +9256,24 @@ "description_md": "Enables or disables buffering of a client request body.\n\nWhen buffering is enabled, the entire request body is\n[read](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_body_buffer_size)\nfrom the client before sending the request to an SCGI server.\n\nWhen buffering is disabled, the request body is sent to the SCGI server\nimmediately as it is received.\nIn this case, the request cannot be passed to the\n[next server](https://nginx.org/en/docs/http/ngx_http_scgi_module.html#scgi_next_upstream)\nif nginx already started sending the request body.\n\nWhen HTTP/1.1 chunked transfer encoding is used\nto send the original request body,\nthe request body will be buffered regardless of the directive value.", "description_html": "Enables or disables buffering of a client request body.
\n\nWhen buffering is enabled, the entire request body is\nread\nfrom the client before sending the request to an SCGI server.
\n\nWhen buffering is disabled, the request body is sent to the SCGI server\nimmediately as it is received.\nIn this case, the request cannot be passed to the\nnext server\nif nginx already started sending the request body.
\n\nWhen HTTP/1.1 chunked transfer encoding is used\nto send the original request body,\nthe request body will be buffered regardless of the directive value.
\n" }, + { + "name": "scgi_request_dynamic", + "default": "off", + "contexts": [ + "http", + "server", + "location" + ], + "syntax_md": [ + "`on` | `off`" + ], + "syntax_html": [ + "on | off
Enables or disables creation of a separate request instance\nfor each SCGI server.\nBy default, a single request is used for all SCGI servers.\nIf the directive is set to the value “on”,\na separate request instance is created,\nallowing per-server request customization.\nFor example, the server-specific “Host” request header field\ncan be set:
proxy_request_dynamic on;\nproxy_set_header Host $upstream_last_server_name;\n\n\n" + }, { "name": "scgi_send_timeout", "default": "60s", @@ -10257,11 +10563,251 @@ ] }, { - "id": "/en/docs/http/ngx_http_upstream_conf_module.html", - "name": "ngx_http_upstream_conf_module", + "id": "/en/docs/http/ngx_http_tunnel_module.html", + "name": "ngx_http_tunnel_module", "directives": [ { - "name": "upstream_conf", + "name": "tunnel_allow_upstream", + "default": "", + "contexts": [ + "http", + "server", + "location" + ], + "syntax_md": [ + "*`string`* ..." + ], + "syntax_html": [ + "This directive is available as part of our\ncommercial subscription.
\n
string …
Defines conditions under which access to the backend server\nis allowed or denied.\nIf all string parameters are not empty\nand not equal to “0” then the access is allowed.\nThe conditions are evaluated each time\nbefore a connection to a backend server is established.\nParameter values can contain variables:
\n\ngeo $upstream_last_addr $allow {\n volatile;\n 10.10.0.0/24 1;\n}\n\nserver {\n listen 127.0.0.1:8080;\n\n tunnel_pass;\n tunnel_allow_upstream $allow;\n}\naddress | off
Makes outgoing connections to a backend server originate\nfrom the specified local IP address with an optional port.\nParameter value can contain variables.\nThe special value off cancels the effect\nof the tunnel_bind directive\ninherited from the previous configuration level, which allows the\nsystem to auto-assign the local IP address and port.
on | off
When enabled, makes the tunnel_bind operation\nat each connection attempt:
geo $upstream_last_addr $bind_addr {\n volatile;\n 10.0.0.0/24 10.0.0.1;\n 192.168.0.0/24 192.168.0.1;\n}\n\ntunnel_bind $bind_addr;\ntunnel_bind_dynamic on;\nsize
Sets the size of the buffer used for reading data\nfrom the backend server.\nAlso sets the size of the buffer used for reading data\nfrom the client.
time
Defines a timeout for establishing a connection with a backend server.\nIt should be noted that this timeout cannot usually exceed 75 seconds.
\n" + }, + { + "name": "tunnel_next_upstream", + "default": "error timeout", + "contexts": [ + "http", + "server", + "location" + ], + "syntax_md": [ + "`error` | `timeout` | `denied` | `off` ..." + ], + "syntax_html": [ + "error | timeout | denied | off …
Specifies in which cases a request should be passed to the next server:
\n\nerror
an error occurred while establishing a connection with the\nserver or reading data from the server;
timeout
a timeout has occurred while establishing a connection with the\nserver, passing a request to it, or reading data from the server;
denied
the server denied\nthe connection;
off
disables passing a request to the next server.
One should bear in mind that passing a request to the next server is\nonly possible if nothing has been sent to a client yet.\nThat is, if an error or timeout occurs in the middle of the\ntransferring of a response, fixing this is impossible.
\n\nThe directive also defines what is considered an\nunsuccessful attempt of communication with a server.\nThe cases of error, timeout,\nand denied\nare always considered unsuccessful attempts,\neven if they are not specified in the directive.
Passing a request to the next server can be limited by\nthe number of tries\nand by time.
\n" + }, + { + "name": "tunnel_next_upstream_timeout", + "default": "0", + "contexts": [ + "http", + "server", + "location" + ], + "syntax_md": [ + "*`time`*" + ], + "syntax_html": [ + "time
Limits the time during which a request can be passed to the\nnext server.\nThe 0 value turns off this limitation.
number
Limits the number of possible tries for passing a request to the\nnext server.\nThe 0 value turns off this limitation.
[address]
Enables handling of CONNECT requests and sets the address of a backend server.\nBy default, the address is\n$host:$request_port and is taken from the client request.\nIn most cases, tunnel_pass does not require\nconfiguring any arguments.
The address can be specified as a domain name or IP address,\nand a port:
\n\ntunnel_pass localhost:9000;\nor as a UNIX-domain socket path:
\n\ntunnel_pass unix:/tmp/backend.socket;\nIf a domain name resolves to several addresses, all of them will be\nused in a round-robin fashion.\nIn addition, an address can be specified as a\nserver group.
\n\nParameter value can contain variables.\nIn this case, if an address is specified as a domain name,\nthe name is searched among the described\nserver groups,\nand, if not found, is determined using a\nresolver.
time
Sets the timeout between two successive read or write operations\non client or backend server connections.\nIf no data is transmitted within this time, the connection is closed.
\n" + }, + { + "name": "tunnel_send_lowat", + "default": "0", + "contexts": [ + "http", + "server", + "location" + ], + "syntax_md": [ + "*`size`*" + ], + "syntax_html": [ + "size
If the directive is set to a non-zero value, nginx will try to\nminimize the number\nof send operations on outgoing connections to a backend server by using either\nNOTE_LOWAT flag of the\nkqueue method,\nor the SO_SNDLOWAT socket option,\nwith the specified size.
This directive is ignored on Linux, Solaris, and Windows.
\n" + }, + { + "name": "tunnel_send_timeout", + "default": "60s", + "contexts": [ + "http", + "server", + "location" + ], + "syntax_md": [ + "*`time`*" + ], + "syntax_html": [ + "time
Sets a timeout for transmitting a request to the backend server.\nThe timeout is set only between two successive write operations,\nnot for the transmission of the whole request.\nIf the backend server does not receive anything within this time,\nthe connection is closed.
\n" + }, + { + "name": "tunnel_socket_keepalive", + "default": "off", + "contexts": [ + "http", + "server", + "location" + ], + "syntax_md": [ + "`on` | `off`" + ], + "syntax_html": [ + "on | off
Configures the “TCP keepalive” behavior\nfor outgoing connections to a backend server.\nBy default, the operating system’s settings are in effect for the socket.\nIf the directive is set to the value “on”, the\nSO_KEEPALIVE socket option is turned on for the socket.
keep server response header fields.\nFor example, the “Server” response header field\nis available through the $upstream_http_server variable.\nThe rules of converting header field names to variable names are the same\nas for the variables that start with the\n“$http_” prefix.\nOnly the header fields from the response of the last server are saved.
keeps the IP address or the path to the UNIX-domain socket\nof the last selected upstream server (1.29.3).
\n\n\n\n" + }, { "name": "$upstream_last_server_name", "description_md": "keeps the name of last selected upstream server (1.25.3);\nallows passing it\n[through SNI](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_ssl_server_name):\n```\nproxy_ssl_server_name on;\nproxy_ssl_name $upstream_last_server_name;\n```\n\n\n> This variable is available as part of our\n> [commercial subscription](https://nginx.com/products/).", @@ -10891,6 +11442,24 @@ "id": "/en/docs/http/ngx_http_uwsgi_module.html", "name": "ngx_http_uwsgi_module", "directives": [ + { + "name": "uwsgi_allow_upstream", + "default": "", + "contexts": [ + "http", + "server", + "location" + ], + "syntax_md": [ + "*`string`* ..." + ], + "syntax_html": [ + "This variable is available as part of our\ncommercial subscription.
\n
string …
Defines conditions under which access to a uwsgi server\nis allowed or denied.\nIf all string parameters are not empty\nand not equal to “0” then the access is allowed.\nThe conditions are evaluated each time\nbefore a connection to a uwsgi server is established.\nParameter values can contain variables:
\n\ngeo $upstream_last_addr $allow {\n volatile;\n 10.10.0.0/24 1;\n}\n\nserver {\n listen 127.0.0.1:8080;\n\n location / {\n uwsgi_pass localhost:9000;\n uwsgi_allow_upstream $allow;\n ...\n }\n}\n\n\n" + }, { "name": "uwsgi_bind", "default": "", @@ -10909,6 +11478,24 @@ "description_md": "Makes outgoing connections to a uwsgi server originate\nfrom the specified local IP address with an optional port (1.11.2).\nParameter value can contain variables (1.3.12).\nThe special value `off` (1.3.12) cancels the effect\nof the `uwsgi_bind` directive\ninherited from the previous configuration level, which allows the\nsystem to auto-assign the local IP address and port.\n\nThe `transparent` parameter (1.11.0) allows\noutgoing connections to a uwsgi server originate\nfrom a non-local IP address,\nfor example, from a real IP address of a client:\n```\nuwsgi_bind $remote_addr transparent;\n```\nIn order for this parameter to work,\nit is usually necessary to run nginx worker processes with the\n[superuser](https://nginx.org/en/docs/ngx_core_module.html#user) privileges.\nOn Linux it is not required (1.13.8) as if\nthe `transparent` parameter is specified, worker processes\ninherit the `CAP_NET_RAW` capability from the master process.\nIt is also necessary to configure kernel routing table\nto intercept network traffic from the uwsgi server.", "description_html": "This directive is available as part of our\ncommercial subscription.
\n
Makes outgoing connections to a uwsgi server originate\nfrom the specified local IP address with an optional port (1.11.2).\nParameter value can contain variables (1.3.12).\nThe special value off (1.3.12) cancels the effect\nof the uwsgi_bind directive\ninherited from the previous configuration level, which allows the\nsystem to auto-assign the local IP address and port.
The transparent parameter (1.11.0) allows\noutgoing connections to a uwsgi server originate\nfrom a non-local IP address,\nfor example, from a real IP address of a client:
uwsgi_bind $remote_addr transparent;\nIn order for this parameter to work,\nit is usually necessary to run nginx worker processes with the\nsuperuser privileges.\nOn Linux it is not required (1.13.8) as if\nthe transparent parameter is specified, worker processes\ninherit the CAP_NET_RAW capability from the master process.\nIt is also necessary to configure kernel routing table\nto intercept network traffic from the uwsgi server.
on | off
When enabled, makes the bind operation\nat each connection attempt.
\n\n\n\n" + }, { "name": "uwsgi_buffer_size", "default": "4k|8k", @@ -11438,14 +12025,14 @@ "location" ], "syntax_md": [ - "`error` | `timeout` | `invalid_header` | `http_500` | `http_503` | `http_403` | `http_404` | `http_429` | `non_idempotent` | `off` ..." + "`error` | `timeout` | `denied` | `invalid_header` | `http_500` | `http_503` | `http_403` | `http_404` | `http_429` | `non_idempotent` | `off` ..." ], "syntax_html": [ - "This directive is available as part of our\ncommercial subscription.
\n
error | timeout | invalid_header | http_500 | http_503 | http_403 | http_404 | http_429 | non_idempotent | off …
error | timeout | denied | invalid_header | http_500 | http_503 | http_403 | http_404 | http_429 | non_idempotent | off …
Specifies in which cases a request should be passed to the next server:
\n\nerror
an error occurred while establishing a connection with the\nserver, passing a request to it, or reading the response header;
timeout
a timeout has occurred while establishing a connection with the\nserver, passing a request to it, or reading the response header;
invalid_header
a server returned an empty or invalid response;
http_500
a server returned a response with the code 500;
http_503
a server returned a response with the code 503;
http_403
a server returned a response with the code 403;
http_404
a server returned a response with the code 404;
http_429
a server returned a response with the code 429 (1.11.13);
non_idempotent
normally, requests with a\nnon-idempotent\nmethod\n(POST, LOCK, PATCH)\nare not passed to the next server\nif a request has been sent to an upstream server (1.9.13);\nenabling this option explicitly allows retrying such requests;
off
disables passing a request to the next server.
One should bear in mind that passing a request to the next server is\nonly possible if nothing has been sent to a client yet.\nThat is, if an error or timeout occurs in the middle of the\ntransferring of a response, fixing this is impossible.
\n\nThe directive also defines what is considered an\nunsuccessful attempt of communication with a server.\nThe cases of error, timeout and\ninvalid_header are always considered unsuccessful attempts,\neven if they are not specified in the directive.\nThe cases of http_500, http_503,\nand http_429 are\nconsidered unsuccessful attempts only if they are specified in the directive.\nThe cases of http_403 and http_404\nare never considered unsuccessful attempts.
Passing a request to the next server can be limited by\nthe number of tries\nand by time.
\n" + "description_md": "Specifies in which cases a request should be passed to the next server:\n- `error`\n\n an error occurred while establishing a connection with the\n server, passing a request to it, or reading the response header;\n- `timeout`\n\n a timeout has occurred while establishing a connection with the\n server, passing a request to it, or reading the response header;\n- `denied`\n\n the server [denied](https://nginx.org/en/docs/http/ngx_http_uwsgi_module.html#uwsgi_allow_upstream)\n the connection (1.29.3);\n \n > This parameter is available as part of our\n > [commercial subscription](https://nginx.com/products/).\n- `invalid_header`\n\n a server returned an empty or invalid response;\n- `http_500`\n\n a server returned a response with the code 500;\n- `http_503`\n\n a server returned a response with the code 503;\n- `http_403`\n\n a server returned a response with the code 403;\n- `http_404`\n\n a server returned a response with the code 404;\n- `http_429`\n\n a server returned a response with the code 429 (1.11.13);\n- `non_idempotent`\n\n normally, requests with a\n [non-idempotent](https://datatracker.ietf.org/doc/html/rfc7231#section-4.2.2)\n method\n (`POST`, `LOCK`, `PATCH`)\n are not passed to the next server\n if a request has been sent to an upstream server (1.9.13);\n enabling this option explicitly allows retrying such requests;\n- `off`\n\n disables passing a request to the next server.\n\nOne should bear in mind that passing a request to the next server is\nonly possible if nothing has been sent to a client yet.\nThat is, if an error or timeout occurs in the middle of the\ntransferring of a response, fixing this is impossible.\n\nThe directive also defines what is considered an\n[unsuccessful attempt](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#max_fails) of communication with a server.\nThe cases of `error`, `timeout`,\n`denied` and\n`invalid_header` are always considered unsuccessful attempts,\neven if they are not specified in the directive.\nThe cases of `http_500`, `http_503`,\nand `http_429` are\nconsidered unsuccessful attempts only if they are specified in the directive.\nThe cases of `http_403` and `http_404`\nare never considered unsuccessful attempts.\n\nPassing a request to the next server can be limited by\n[the number of tries](https://nginx.org/en/docs/http/ngx_http_uwsgi_module.html#uwsgi_next_upstream_tries)\nand by [time](https://nginx.org/en/docs/http/ngx_http_uwsgi_module.html#uwsgi_next_upstream_timeout).", + "description_html": "Specifies in which cases a request should be passed to the next server:
\n\nerror
an error occurred while establishing a connection with the\nserver, passing a request to it, or reading the response header;
timeout
a timeout has occurred while establishing a connection with the\nserver, passing a request to it, or reading the response header;
denied
the server denied\nthe connection (1.29.3);
\n\n\n\nThis parameter is available as part of our\ncommercial subscription.
\n
invalid_header
a server returned an empty or invalid response;
http_500
a server returned a response with the code 500;
http_503
a server returned a response with the code 503;
http_403
a server returned a response with the code 403;
http_404
a server returned a response with the code 404;
http_429
a server returned a response with the code 429 (1.11.13);
non_idempotent
normally, requests with a\nnon-idempotent\nmethod\n(POST, LOCK, PATCH)\nare not passed to the next server\nif a request has been sent to an upstream server (1.9.13);\nenabling this option explicitly allows retrying such requests;
off
disables passing a request to the next server.
One should bear in mind that passing a request to the next server is\nonly possible if nothing has been sent to a client yet.\nThat is, if an error or timeout occurs in the middle of the\ntransferring of a response, fixing this is impossible.
\n\nThe directive also defines what is considered an\nunsuccessful attempt of communication with a server.\nThe cases of error, timeout,\ndenied and\ninvalid_header are always considered unsuccessful attempts,\neven if they are not specified in the directive.\nThe cases of http_500, http_503,\nand http_429 are\nconsidered unsuccessful attempts only if they are specified in the directive.\nThe cases of http_403 and http_404\nare never considered unsuccessful attempts.
Passing a request to the next server can be limited by\nthe number of tries\nand by time.
\n" }, { "name": "uwsgi_next_upstream_timeout", @@ -11626,6 +12213,24 @@ "description_md": "Enables or disables buffering of a client request body.\n\nWhen buffering is enabled, the entire request body is\n[read](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_body_buffer_size)\nfrom the client before sending the request to a uwsgi server.\n\nWhen buffering is disabled, the request body is sent to the uwsgi server\nimmediately as it is received.\nIn this case, the request cannot be passed to the\n[next server](https://nginx.org/en/docs/http/ngx_http_uwsgi_module.html#uwsgi_next_upstream)\nif nginx already started sending the request body.\n\nWhen HTTP/1.1 chunked transfer encoding is used\nto send the original request body,\nthe request body will be buffered regardless of the directive value.", "description_html": "Enables or disables buffering of a client request body.
\n\nWhen buffering is enabled, the entire request body is\nread\nfrom the client before sending the request to a uwsgi server.
\n\nWhen buffering is disabled, the request body is sent to the uwsgi server\nimmediately as it is received.\nIn this case, the request cannot be passed to the\nnext server\nif nginx already started sending the request body.
\n\nWhen HTTP/1.1 chunked transfer encoding is used\nto send the original request body,\nthe request body will be buffered regardless of the directive value.
\n" }, + { + "name": "uwsgi_request_dynamic", + "default": "off", + "contexts": [ + "http", + "server", + "location" + ], + "syntax_md": [ + "`on` | `off`" + ], + "syntax_html": [ + "on | off
Enables or disables creation of a separate request instance\nfor each uwsgi server.\nBy default, a single request is used for all uwsgi servers.\nIf the directive is set to the value “on”,\na separate request instance is created,\nallowing per-server request customization.\nFor example, the server-specific “Host” request header field\ncan be set:
proxy_request_dynamic on;\nproxy_set_header Host $upstream_last_server_name;\n\n\n" + }, { "name": "uwsgi_send_timeout", "default": "60s", @@ -15542,6 +16147,28 @@ } ] }, + { + "id": "/en/docs/stream/ngx_stream_num_map_module.html", + "name": "ngx_stream_num_map_module", + "directives": [ + { + "name": "num_map", + "default": "", + "contexts": [ + "stream" + ], + "syntax_md": [ + "[*`$number`*] *`$variable`* `{...}`" + ], + "syntax_html": [ + "This directive is available as part of our\ncommercial subscription.
\n
[$number] $variable {...}
Describes how the values of the specified variable depend on numeric values\nor numeric value ranges.
\n\n\n\n\nSince variables are evaluated only when used, the mere existence\nof even a large number of declared “
\nnum_map” variables\ndoes not cause any extra costs for connection processing.
Parameters inside the num_map block specify a mapping\nbetween source and resulting values.
Source values are specified as numbers or as numeric ranges.
\n\nThe following special parameters are also supported:
\n\ndefault
sets the resulting value if the source value matches none\nof the specified variants.\nWhen default is not specified, the default\nresulting value will be an empty string.
include
includes a file with values.\nThere can be several inclusions.
volatile
indicates that the variable is not cacheable.
Makes outgoing connections to a proxied server originate\nfrom the specified local IP address.\nParameter value can contain variables (1.11.2).\nThe special value off cancels the effect\nof the proxy_bind directive\ninherited from the previous configuration level, which allows the\nsystem to auto-assign the local IP address.
The transparent parameter (1.11.0) allows\noutgoing connections to a proxied server originate\nfrom a non-local IP address,\nfor example, from a real IP address of a client:
proxy_bind $remote_addr transparent;\nIn order for this parameter to work,\nit is usually necessary to run nginx worker processes with the\nsuperuser privileges.\nOn Linux it is not required (1.13.8) as if\nthe transparent parameter is specified, worker processes\ninherit the CAP_NET_RAW capability from the master process.\nIt is also necessary to configure kernel routing table\nto intercept network traffic from the proxied server.
on | off
When enabled, makes the bind operation\nat each connection attempt.
\n\n\n\n" + }, { "name": "proxy_buffer_size", "default": "16k", @@ -17144,6 +17788,11 @@ "description_md": "time to receive the first byte of data (1.11.4);\nthe time is kept in seconds with millisecond resolution.\nTimes of several connections\nare separated by commas like addresses in the\n[$upstream_addr](https://nginx.org/en/docs/stream/ngx_stream_upstream_module.html#var_upstream_addr) variable.", "description_html": "This directive is available as part of our\ncommercial subscription.
\n
time to receive the first byte of data (1.11.4);\nthe time is kept in seconds with millisecond resolution.\nTimes of several connections\nare separated by commas like addresses in the\n$upstream_addr variable.
\n" }, + { + "name": "$upstream_last_addr", + "description_md": "keeps the IP address or the path to the UNIX-domain socket\nof the last selected upstream server (1.29.3).\n\n\n> This variable is available as part of our\n> [commercial subscription](https://nginx.com/products/).", + "description_html": "keeps the IP address or the path to the UNIX-domain socket\nof the last selected upstream server (1.29.3).
\n\n\n\n" + }, { "name": "$upstream_session_time", "description_md": "session duration in seconds with millisecond resolution (1.11.4).\nTimes of several connections\nare separated by commas like addresses in the\n[$upstream_addr](https://nginx.org/en/docs/stream/ngx_stream_upstream_module.html#var_upstream_addr) variable.", @@ -17513,5 +18162,5 @@ ] } ], - "version": "https://github.com/nginx/nginx.org/commit/2a1517c5cdaaf2d3fc90dc289278f7d1afffe491" + "version": "https://github.com/nginx/nginx.org/commit/d90d0b7854816078daf804d188ee160e9edbf536" }This variable is available as part of our\ncommercial subscription.
\n