{"id":21613,"date":"2026-09-21T08:33:31","date_gmt":"2026-09-21T06:33:31","guid":{"rendered":"https:\/\/webhosting.de\/nginx-upstream-keepalive-optimal-konfigurieren-reverse-proxy-netzwerk\/"},"modified":"2026-09-21T08:33:31","modified_gmt":"2026-09-21T06:33:31","slug":"configurar-de-forma-ideal-o-keepalive-do-upstream-do-nginx-em-rede-de-proxy-reverso","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/nginx-upstream-keepalive-optimal-konfigurieren-reverse-proxy-netzwerk\/","title":{"rendered":"Configurar o Keepalive do Upstream do NGINX de forma ideal para obter o m\u00e1ximo desempenho como proxy inverso"},"content":{"rendered":"<p>Configurarei o Keepalive do Upstream do NGINX de forma a que o proxy reverso estabele\u00e7a menos liga\u00e7\u00f5es, ofere\u00e7a menores lat\u00eancias e absorva de forma fi\u00e1vel os picos de carga. Para tal, ajustarei <strong>Dimens\u00f5es da piscina<\/strong>, limites de tempo e cabe\u00e7alhos de forma espec\u00edfica, para que as liga\u00e7\u00f5es sejam reutilizadas e o percurso de dados se mantenha otimizado.<\/p>\n\n<h2>Pontos centrais<\/h2>\n\n<ul>\n  <li><strong>HTTP\/1.1<\/strong> for\u00e7ar e limpar os cabe\u00e7alhos de liga\u00e7\u00e3o<\/li>\n  <li><strong>keepalive<\/strong> dimensionar corretamente por trabalhador<\/li>\n  <li><strong>Intervalos<\/strong> adaptar aos valores do backend<\/li>\n  <li><strong>Pedidos\/Liga\u00e7\u00e3o<\/strong> reduzir e reciclar<\/li>\n  <li><strong>Monitoriza\u00e7\u00e3o<\/strong> para a velocidade de liga\u00e7\u00e3o e a lat\u00eancia<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/nginx-serverkonfiguration-8234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Por que \u00e9 que o Upstream Keepalive reduz drasticamente o esfor\u00e7o de estabelecimento de liga\u00e7\u00f5es<\/h2>\n\n<p>Sem reutiliza\u00e7\u00e3o, o NGINX abre uma nova liga\u00e7\u00e3o ao backend por cada pedido, o que implica handshakes adicionais, mais ciclos de CPU e recursos adicionais do kernel; \u00e9 precisamente aqui que entra em a\u00e7\u00e3o <strong>Manter vivo<\/strong> . Configurei o NGINX para armazenar em cache os sockets j\u00e1 estabelecidos que se encontram inativos e para os utilizar em pedidos subsequentes, o que reduz significativamente os tempos de liga\u00e7\u00e3o. Isto diminui a taxa de liga\u00e7\u00f5es por segundo, reduz os picos de backlog e limita as mudan\u00e7as de contexto no sistema operativo. Especialmente no caso do TLS para o backend, poupo tempo de forma significativa atrav\u00e9s da reutiliza\u00e7\u00e3o de sess\u00f5es. Desta forma, a cadeia de respostas mant\u00e9m-se est\u00e1vel mesmo com um elevado d\u00e9bito <strong>fi\u00e1vel<\/strong> e responde com fluidez.<\/p>\n\n<h2>Princ\u00edpio b\u00e1sico e a diretiva keepalive no upstream<\/h2>\n\n<p>A diretiva <strong>keepalive<\/strong> No bloco \u201eupstream\u201c, limita-se o n\u00famero de liga\u00e7\u00f5es backend inativas armazenadas em cache por cada worker. Este limite n\u00e3o se aplica globalmente, mas sim estritamente a cada processo worker, raz\u00e3o pela qual estou sempre atento ao n\u00famero de workers. Quando o pool est\u00e1 cheio, o NGINX encerra primeiro a liga\u00e7\u00e3o que est\u00e1 inativa h\u00e1 mais tempo, para que haja espa\u00e7o para novos sockets. Para a reutiliza\u00e7\u00e3o, o lado do proxy necessita de HTTP\/1.1 e de um cabe\u00e7alho \u00abConnection\u00bb neutralizado. Sem estes pr\u00e9-requisitos, o pool permanece vazio, apesar de eu definir \u00abkeepalive\u00bb no upstream, o que muitos administradores <strong>no in\u00edcio<\/strong> surpreendido.<\/p>\n\n<pre><code>upstream backend_pool {\n    server 192.168.1.10:8080;\n    server 192.168.1.11:8080;\n    server 192.168.1.12:8080;\n\n    keepalive 32; # liga\u00e7\u00f5es inativas por trabalhador\n    keepalive_requests 1000;   # reciclagem ap\u00f3s N pedidos\n    keepalive_timeout 60s;     # tempo de inatividade\n}\n\nservidor {\n    escutar 80;\n    localiza\u00e7\u00e3o \/ {\n proxy_pass http:\/\/backend_pool;\n proxy_http_version 1.1;\n proxy_set_header Connection \"\";\n    }\n}\n<\/code><\/pre>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/nginx_upstream_keepalive_3471.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Diretivas obrigat\u00f3rias no bloco \u00abLocation\u00bb: HTTP\/1.1 e controlo de cabe\u00e7alhos<\/h2>\n\n<p>Obrigo o NGINX a utilizar o HTTP\/1.1 no caminho do proxy, porque o Keepalive n\u00e3o funciona corretamente com o HTTP\/1.0 e as liga\u00e7\u00f5es terminam desnecessariamente; a diretiva <strong>vers\u00e3o_do_proxy_http<\/strong> 1.1 \u00e9, portanto, obrigat\u00f3rio. Al\u00e9m disso, removo o cabe\u00e7alho \u201eConnection\u201c das solicita\u00e7\u00f5es normais, para que o backend n\u00e3o receba uma instru\u00e7\u00e3o \u201eclose\u201c. Para atualiza\u00e7\u00f5es como WebSockets, defino especificamente \u00abConnection: Upgrade\u00bb atrav\u00e9s de um mapa, sem comprometer a reutiliza\u00e7\u00e3o normal. Desta forma, a pol\u00edtica de liga\u00e7\u00e3o mant\u00e9m-se consistente e desacoplada dos cabe\u00e7alhos do cliente. \u00c9 precisamente esta pequena altera\u00e7\u00e3o que evita muitos problemas dif\u00edceis de identificar <strong>Imagens de erros<\/strong>.<\/p>\n\n<pre><code>location \/ {\n    proxy_pass http:\/\/backend_pool;\n    proxy_http_version 1.1;\n    proxy_set_header Connection \"\";\n    proxy_set_header Upgrade $http_upgrade;\n    proxy_set_header Connection $connection_upgrade;\n}\n\nmap $http_upgrade $connection_upgrade {\n    default upgrade;\n    \"\" \"\";\n}\n<\/code><\/pre>\n\n<h2>Controlo de precis\u00e3o: selecionar corretamente os valores de keepalive_requests e keepalive_timeout<\/h2>\n\n<p>Com dois parafusos de ajuste, controlo a dura\u00e7\u00e3o e a renova\u00e7\u00e3o das liga\u00e7\u00f5es, para que a piscina se mantenha atualizada e n\u00e3o haja sockets abandonados a causar problemas; estes s\u00e3o <strong>keepalive_requests<\/strong> e keepalive_timeout. Ap\u00f3s N pedidos, o NGINX encerra a liga\u00e7\u00e3o de forma seletiva e restabelece-a, se necess\u00e1rio, o que atenua os efeitos de envelhecimento na rede. Costumo definir o tempo de inatividade (Idle Timeout) num valor bastante curto, geralmente entre 30 e 120 segundos, para que os backends n\u00e3o interrompam a liga\u00e7\u00e3o antes do tempo. O importante \u00e9 o equil\u00edbrio: o valor do NGINX nunca deve ser superior ao tempo de espera dos servidores de aplica\u00e7\u00f5es, caso contr\u00e1rio, as reinicializa\u00e7\u00f5es de liga\u00e7\u00e3o multiplicam-se. Quem quiser aprofundar os conceitos encontrar\u00e1 dicas pr\u00e1ticas no artigo <a href=\"https:\/\/webhosting.de\/pt\/http-keepalive-timeout-configuracao-do-desempenho-do-servidor\/\">Tempo limite de keepalive<\/a>, que explica os valores t\u00edpicos e as intera\u00e7\u00f5es.<\/p>\n\n<p>Para uma orienta\u00e7\u00e3o r\u00e1pida, apresento os valores iniciais mais comuns e a respetiva finalidade numa tabela clara <strong>Tabela<\/strong>. Os valores de refer\u00eancia servem como ponto de partida e, ap\u00f3s a monitoriza\u00e7\u00e3o, acabam por ficar frequentemente um pouco acima ou abaixo desses valores. Um per\u00edodo demasiado curto gera recria\u00e7\u00f5es desnecess\u00e1rias, enquanto um per\u00edodo demasiado longo mant\u00e9m liga\u00e7\u00f5es antigas. O n\u00famero de pedidos por liga\u00e7\u00e3o protege-me de valores at\u00edpicos, sem esvaziar o conjunto. Com estes dados-chave, consigo obter resultados muito rapidamente <strong>Predefini\u00e7\u00f5es<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Par\u00e2metros<\/th>\n      <th>Objetivo<\/th>\n      <th>valor de refer\u00eancia<\/th>\n      <th>Nota sobre o tuning<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>keepalive<\/td>\n      <td>Tamanho do conjunto de processos inativos por trabalhador<\/td>\n      <td>32-64<\/td>\n      <td>Ajustar \u00e0 carga simult\u00e2nea por trabalhador<\/td>\n    <\/tr>\n    <tr>\n      <td>keepalive_requests<\/td>\n      <td>Pedidos m\u00e1ximos por liga\u00e7\u00e3o<\/td>\n      <td>500\u20131000<\/td>\n      <td>Em transmiss\u00f5es longas, defina um valor ligeiramente superior<\/td>\n    <\/tr>\n    <tr>\n      <td>tempo de espera de keepalive<\/td>\n      <td>Tempo m\u00e1ximo de inatividade por liga\u00e7\u00e3o<\/td>\n      <td>anos 60<\/td>\n      <td>Tempo de espera de inatividade do backend mais curto ou igual<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Determinar o tamanho do pool com base nas liga\u00e7\u00f5es simult\u00e2neas<\/h2>\n\n<p>N\u00e3o escolho o tamanho do pool com base no n\u00famero de pedidos por segundo, mas sim com base em <strong>Concorr\u00eancia<\/strong> por worker. Primeiro, calculo o n\u00famero m\u00e9dio e o n\u00famero m\u00e1ximo de pedidos paralelos ao backend. Em seguida, divido esses valores pelo n\u00famero de workers do NGINX e arredondo para cima. Para 200 pedidos simult\u00e2neos com quatro workers, chego a um valor de cerca de 50 por worker, pelo que o valor inicial de keepalive 64 \u00e9 adequado. Desta forma, mantenho os sockets dispon\u00edveis sem abrir um n\u00famero desnecess\u00e1rio de <strong>Liga\u00e7\u00f5es<\/strong> para ligar.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/nginx-reverse-proxy-setup-5038.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Aproveitar deliberadamente as funcionalidades espec\u00edficas das vers\u00f5es mais recentes do NGINX<\/h2>\n\n<p>As vers\u00f5es atuais permitem, muitas vezes por predefini\u00e7\u00e3o, a reutiliza\u00e7\u00e3o, mas estabelecem limites bastante conservadores; mesmo assim, vou indicar os valores <strong>expl\u00edcito<\/strong> . Isto garante a reprodutibilidade, facilita o ajuste e evita surpresas ap\u00f3s uma atualiza\u00e7\u00e3o. Atrav\u00e9s do par\u00e2metro \u201elocal\u201c, posso, opcionalmente, limitar a reutiliza\u00e7\u00e3o a uma localiza\u00e7\u00e3o espec\u00edfica, caso os perfis de seguran\u00e7a ou as pol\u00edticas de cabe\u00e7alhos sejam diferentes. Desta forma, a separa\u00e7\u00e3o mant\u00e9m-se clara, sem perder globalmente as vantagens da reutiliza\u00e7\u00e3o. Com valores claros, documento as inten\u00e7\u00f5es e poupo trabalho mais tarde <strong>Tempo de an\u00e1lise<\/strong>.<\/p>\n\n<h2>Monitoriza\u00e7\u00e3o e m\u00e9tricas: a configura\u00e7\u00e3o est\u00e1 realmente a funcionar?<\/h2>\n\n<p>Come\u00e7o por verificar o n\u00famero de novas liga\u00e7\u00f5es ao backend por segundo; uma diminui\u00e7\u00e3o significativa indica que as medidas est\u00e3o a surtir efeito <strong>Reutiliza\u00e7\u00e3o<\/strong>. Em seguida, observo o \u00abupstream_connect_time\u00bb, que se situa pr\u00f3ximo de zero quando h\u00e1 acertos no pool. Erros nos registos, especialmente reinicializa\u00e7\u00f5es de liga\u00e7\u00e3o, indicam limites de tempo que est\u00e3o por tr\u00e1s dos valores do backend. Al\u00e9m disso, correlaciono a utiliza\u00e7\u00e3o da CPU do backend e as lat\u00eancias com a percentagem de liga\u00e7\u00f5es reutilizadas. Para uma compreens\u00e3o mais aprofundada da <a href=\"https:\/\/webhosting.de\/pt\/ligacao-http-reutilizacao-keepalive-otimizacao-serverperf-boost\/\">Reutiliza\u00e7\u00e3o de liga\u00e7\u00f5es<\/a> S\u00e3o \u00fateis exemplos que mostram os efeitos em diferentes padr\u00f5es de carga.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/nginx_keepalive_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Eliminar rapidamente as fontes de erro t\u00edpicas<\/h2>\n\n<p>Se n\u00e3o houver HTTP\/1.1 para o backend, as liga\u00e7\u00f5es ter\u00e3o uma dura\u00e7\u00e3o curta, independentemente do valor que eu <strong>keepalive<\/strong> defino. Se o cliente enviar \u201eConnection: close\u201c e eu passar o cabe\u00e7alho sem filtrar, o backend encerra cada liga\u00e7\u00e3o imediatamente ap\u00f3s a resposta. Se os tempos de espera de inatividade n\u00e3o coincidirem, o lado da aplica\u00e7\u00e3o encerra a liga\u00e7\u00e3o primeiro e o NGINX recebe um rein\u00edcio na pr\u00f3xima solicita\u00e7\u00e3o. Um pool sobredimensionado mant\u00e9m demasiados sockets abertos e desperdi\u00e7a mem\u00f3ria e portas. Verifico estes quatro pontos em cada an\u00e1lise como <strong>Primeiro<\/strong>, porque explicam 90 % de todos os problemas.<\/p>\n\n<h2>Exemplo pr\u00e1tico: configura\u00e7\u00e3o de refer\u00eancia para elevado d\u00e9bito<\/h2>\n\n<p>Com apenas algumas instru\u00e7\u00f5es, consigo tornar um proxy sobrecarregado num servidor r\u00e1pido e fi\u00e1vel e garantir um reencaminhamento correto dos cabe\u00e7alhos; o modelo seguinte tem-se revelado eficaz e \u00e9 f\u00e1cil de <strong>personalizar<\/strong>. Defino o keepalive para 64, limito as solicita\u00e7\u00f5es por liga\u00e7\u00e3o a 1000 e mantenho um tempo de inatividade de 60 segundos. Al\u00e9m disso, transmito corretamente as informa\u00e7\u00f5es de host e de reencaminhamento, para que os backends possam aplicar a l\u00f3gica e a limita\u00e7\u00e3o de taxa. Esta combina\u00e7\u00e3o poupa a CPU, reduz os tempos de resposta e permite lidar com picos de carga de forma mais tranquila. \u00c9 exatamente assim que consigo uma <strong>Desempenho<\/strong>.<\/p>\n\n<pre><code>upstream app_backend {\n    server 10.0.1.10:3000 max_fails=2 fail_timeout=30s;\n    server 10.0.1.11:3000 max_fails=2 fail_timeout=30s;\n\n    keepalive 64;\n    keepalive_requests 1000;\n    keepalive_timeout 60s;\n}\n\nserver {\n    listen 80;\n    server_name example.com;\n\n    location \/ {\n proxy_pass http:\/\/app_backend;\n proxy_http_version 1.1;\n proxy_set_header Connection \"\";\n proxy_set_header Host $host;\n        proxy_set_header X-Real-IP $remote_addr;\n        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;\n proxy_set_header X-Forwarded-Proto $scheme;\n    }\n}\n<\/code><\/pre>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/nginx-keepalive-setup-3294.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ambientes de alojamento e aspetos operacionais que realmente importam<\/h2>\n\n<p>Costumo colocar o NGINX \u00e0 frente do PHP-FPM, do Node.js ou dos servi\u00e7os Java e certifico-me de que as lat\u00eancias de rede se mant\u00eam baixas e que os tempos limite do backend s\u00e3o consistentes; isto proporciona <strong>Planeamento<\/strong>. Uma configura\u00e7\u00e3o de rede s\u00f3lida ao n\u00edvel do kernel, com limites de sockets adequados, evita que um grande n\u00famero de liga\u00e7\u00f5es abertas entre em conflito. A distribui\u00e7\u00e3o equilibrada da CPU e os percursos de armazenamento r\u00e1pidos ajudam os backends a manter tempos de resposta curtos. Al\u00e9m disso, garanto que as configura\u00e7\u00f5es sejam versionadas, para que as altera\u00e7\u00f5es permane\u00e7am rastre\u00e1veis. Com esta disciplina, o sistema mant\u00e9m-se est\u00e1vel mesmo em picos de tr\u00e1fego <strong>reag\u00edvel<\/strong>.<\/p>\n\n<h2>Melhores pr\u00e1ticas para opera\u00e7\u00f5es em curso<\/h2>\n\n<p>Come\u00e7o com um keepalive de 32\u201364, 500\u20131000 pedidos por liga\u00e7\u00e3o e 60 segundos de tempo de inatividade; depois, fa\u00e7o medi\u00e7\u00f5es sistem\u00e1ticas e ajusto os valores; isto permite obter resultados r\u00e1pidos <strong>sucessos<\/strong>. Acompanho cada altera\u00e7\u00e3o com m\u00e9tricas relativas \u00e0 taxa de liga\u00e7\u00e3o, lat\u00eancia e padr\u00f5es de erros, at\u00e9 que as curvas se estabilizem. Ajusto o tamanho do pool com base nas solicita\u00e7\u00f5es simult\u00e2neas, e n\u00e3o na taxa de transfer\u00eancia bruta por segundo. Os tempos de espera nunca devem ser superiores aos dos seus equivalentes na pilha de back-end; caso contr\u00e1rio, h\u00e1 risco de reinicializa\u00e7\u00f5es espor\u00e1dicas. Quem quiser ajustar os par\u00e2metros com maior precis\u00e3o encontrar\u00e1 orienta\u00e7\u00f5es sobre o ajuste fino em <a href=\"https:\/\/webhosting.de\/pt\/otimizar-os-pedidos-keepalive-do-nginx-ajuste-do-desempenho-do-servidor-web\/\">Otimizar os pedidos Keepalive<\/a>, o que torna a reciclagem bastante f\u00e1cil de gerir.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/nginx-server-einstellung-7845.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Sincroniza\u00e7\u00e3o dos tempos de espera do proxy e do TCP Keepalive<\/h2>\n\n<p>Para al\u00e9m dos par\u00e2metros de keepalive propriamente ditos, ajusto com precis\u00e3o os limites de tempo de transporte. A tr\u00edade composta por <strong>tempo limite de liga\u00e7\u00e3o do proxy<\/strong>, <strong>proxy_send_timeout<\/strong> e <strong>tempo_limite_de_leitura_proxy<\/strong> determina o n\u00edvel de paci\u00eancia do NGINX ao estabelecer liga\u00e7\u00f5es, enviar e receber dados. Nunca defino estes valores acima dos correspondentes no backend, mas sim ligeiramente abaixo, para que os erros sejam detetados atempadamente e n\u00e3o se agravem no lado da aplica\u00e7\u00e3o. Al\u00e9m disso, ativo <strong>proxy_socket_keepalive<\/strong>, para que o sistema operativo envie sinais de vida a intervalos regulares atrav\u00e9s de sockets inativos e detete liga\u00e7\u00f5es semiabertas. Isto evita que as liga\u00e7\u00f5es inativas permane\u00e7am no conjunto e provoquem picos de lat\u00eancia na pr\u00f3xima solicita\u00e7\u00e3o.<\/p>\n\n<pre><code>server {\n    listen 80;\n\n    location \/ {\n proxy_pass http:\/\/backend_pool;\n\n proxy_connect_timeout 3s;   # falhar rapidamente se n\u00e3o for poss\u00edvel estabelecer liga\u00e7\u00e3o\n proxy_send_timeout    30s;  # Grava\u00e7\u00e3o no backend\n proxy_read_timeout    30s;  # Respostas do backend\n proxy_socket_keepalive on;  # Ativar o keepalive TCP do sistema operativo\n    }\n}\n<\/code><\/pre>\n\n<p>No caso de fluxos de longa dura\u00e7\u00e3o (por exemplo, SSE ou WebSockets), aumentei apenas o tempo limite de leitura, mantendo o tempo limite de liga\u00e7\u00e3o inalterado. Desta forma, consigo reagir rapidamente a destinos com falhas, mas deixo que as respostas leg\u00edtimas e demoradas sejam processadas sem interrup\u00e7\u00f5es.<\/p>\n\n<h2>Planeamento de recursos: worker_connections, FDs e portas ef\u00e9meras<\/h2>\n\n<p>Um conjunto de keepalive limpo n\u00e3o serve de nada se os limites dos descritores de ficheiros ou os intervalos de portas se esgotarem. Por isso, pretendo <strong>liga\u00e7\u00f5es_trabalhadores<\/strong> e <strong>worker_rlimit_nofile<\/strong> com margem de seguran\u00e7a. Fa\u00e7o um c\u00e1lculo aproximado: FDs abertas \u2248 (liga\u00e7\u00f5es simult\u00e2neas de clientes + liga\u00e7\u00f5es simult\u00e2neas ao backend + sockets inativos agrupados) por trabalhador. Se utilizar v\u00e1rios upstreams com pools, a necessidade multiplica-se. Da mesma forma, presto aten\u00e7\u00e3o \u00e0 faixa de portas ef\u00e9meras do sistema, uma vez que o NGINX atua como cliente TCP em dire\u00e7\u00e3o ao backend e acumula estados TIME_WAIT.<\/p>\n\n<pre><code>worker_processes auto;\nworker_rlimit_nofile 131072;\n\nevents {\n    worker_connections 8192;\n}\n<\/code><\/pre>\n\n<pre><code>Exemplos do Linux para # (sysctl):\nnet.core.somaxconn = 4096\nnet.ipv4.ip_local_port_range = 10240 65535\nnet.ipv4.tcp_fin_timeout = 15\n<\/code><\/pre>\n\n<p>Adoto uma abordagem conservadora: n\u00e3o elimino o TIME_WAIT de forma agressiva, mas reduzo a taxa de liga\u00e7\u00f5es atrav\u00e9s do Keepalive. Desta forma, os par\u00e2metros do kernel permanecem n\u00e3o cr\u00edticos e o comportamento \u00e9 previs\u00edvel.<\/p>\n\n<h2>Zonas a montante, estrat\u00e9gia de balanceamento e rota\u00e7\u00e3o de DNS<\/h2>\n\n<p>Quando h\u00e1 v\u00e1rios workers, partilho o estado do Balancer atrav\u00e9s de uma <strong>zona<\/strong>, para que as falhas e os pesos se mantenham consistentes. Os sockets keepalive continuam a ser atribu\u00eddos por trabalhador, mas a distribui\u00e7\u00e3o torna-se mais uniforme. No caso de backends din\u00e2micos que mudam de endere\u00e7o atrav\u00e9s do DNS, defino \u201e<strong>resolver<\/strong>\u201c nas linhas do servidor e defina um <strong>resolver<\/strong>. Importante: quando os endere\u00e7os IP s\u00e3o alternados, o conjunto n\u00e3o recicla imediatamente todos os sockets antigos; por isso, considero que <em>keepalive_requests<\/em> e prazos realistas, para que a renova\u00e7\u00e3o tenha efeito rapidamente.<\/p>\n\n<pre><code>upstream backend_pool {\n    zone backend_zone 128k;  # partilha o estado do balanceador\n    least_conn; # distribui\u00e7\u00e3o equitativa em pedidos longos\n\n server app-1.internal:8080 resolve;\n    server app-2.internal:8080 resolve;\n\n keepalive 64;\n    keepalive_requests 1000;\n    keepalive_timeout 60s;\n}\n\nresolver 10.0.0.2 valid=30s;\nresolver_timeout 5s;\n\nproxy_next_upstream error timeout http_502 http_504;\nproxy_next_upstream_tries 2;  # repeti\u00e7\u00f5es poucas e espec\u00edficas\n<\/code><\/pre>\n\n<p>Para sess\u00f5es ligadas a um n\u00f3 de backend espec\u00edfico (por exemplo, \u00absticky state\u00bb), combino a reutiliza\u00e7\u00e3o com <em>ip_hash<\/em> ou um mecanismo de sess\u00e3o externo. Isto evita que o agrupamento de liga\u00e7\u00f5es comprometa a coer\u00eancia da sess\u00e3o.<\/p>\n\n<h2>TLS para o backend: SNI, reutiliza\u00e7\u00e3o de sess\u00f5es e algoritmos de encripta\u00e7\u00e3o<\/h2>\n\n<p>Quanto mais o TLS for utilizado no percurso do backend, mais valioso \u00e9 o Keepalive. Ativo o SNI, defino o nome esperado e garanto a reutiliza\u00e7\u00e3o da sess\u00e3o TLS. Isto reduz os custos do handshake e suaviza os picos de lat\u00eancia. Escolho as conjuntos de encripta\u00e7\u00e3o e os protocolos de forma restritiva, sem excluir backends mais antigos. Na verifica\u00e7\u00e3o de certificados (opcional), a cadeia de confian\u00e7a tem de estar completa; caso contr\u00e1rio, as liga\u00e7\u00f5es falham esporadicamente.<\/p>\n\n<pre><code>upstream https_backend {\n    server backend.example.local:443;\n    keepalive 32;\n}\n\nserver {\n    listen 443 ssl;\n\n location \/ {\n proxy_pass https:\/\/https_backend;\n proxy_http_version 1.1;\n proxy_set_header Connection \"\";\n\n        proxy_ssl_server_name on;\n proxy_ssl_name backend.example.local;\n proxy_ssl_session_reuse on;\n proxy_ssl_protocols TLSv1.2 TLSv1.3;\n        proxy_ssl_ciphers HIGH:!aNULL:!MD5;\n # opcional: proxy_ssl_verify on;\n # opcional: proxy_ssl_trusted_certificate \/etc\/nginx\/ca.pem;\n    }\n}\n<\/code><\/pre>\n\n<p>Se eu pr\u00f3prio controlar o lado do backend, ativo l\u00e1 os tickets ou caches de sess\u00e3o e verifico, atrav\u00e9s de m\u00e9tricas, se as taxas de retoma aumentam. Em combina\u00e7\u00e3o com o Keepalive, consigo assim tempos de liga\u00e7\u00e3o e de handshake consistentemente baixos.<\/p>\n\n<h2>Casos especiais: gRPC, WebSockets e autentica\u00e7\u00e3o ligada \u00e0 liga\u00e7\u00e3o<\/h2>\n\n<p>Em <strong>gRPC<\/strong> O NGINX funciona a montante atrav\u00e9s de HTTP\/2. Neste caso, um n\u00famero reduzido de liga\u00e7\u00f5es de longa dura\u00e7\u00e3o com muitos fluxos costuma proporcionar os melhores resultados; o conjunto de liga\u00e7\u00f5es mant\u00e9m-se pequeno, mas est\u00e1vel. Para <strong>WebSockets<\/strong> Defino tempos de espera de leitura longos e mantenho a l\u00f3gica dos cabe\u00e7alhos da solu\u00e7\u00e3o \u00abmap\u00bb, para que as liga\u00e7\u00f5es de atualiza\u00e7\u00e3o n\u00e3o sejam encerradas acidentalmente. <strong>NTLM<\/strong> ou outras formas de autentica\u00e7\u00e3o ligadas \u00e0 liga\u00e7\u00e3o exigem o \u00abconnection pinning\u00bb; separo esses percursos em localiza\u00e7\u00f5es pr\u00f3prias e reduzo a\u00ed o pooling ou a reutiliza\u00e7\u00e3o, para que os handshakes de seguran\u00e7a n\u00e3o se misturem entre clientes.<\/p>\n\n<pre><code>Exemplo de gRPC #\nlocation \/grpc.Service\/ {\n    grpc_pass grpc:\/\/backend_pool;\n    grpc_read_timeout 300s;  Permitir fluxos longos #\n}\n<\/code><\/pre>\n\n<p>\u00c9 fundamental definir uma pol\u00edtica de liga\u00e7\u00e3o consistente para cada caminho e utilizar o Keepalive de forma generalizada apenas nos casos em que tal n\u00e3o seja semanticamente cr\u00edtico.<\/p>\n\n<h2>A mensurabilidade na pr\u00e1tica: registos de acesso com tempos de upstream<\/h2>\n\n<p>Estou a ampliar o registo de acesso com m\u00e9tricas de upstream. Desta forma, consigo perceber \u00e0 primeira vista se uma resposta prov\u00e9m de um socket em pool (tempo de liga\u00e7\u00e3o muito curto) e com que frequ\u00eancia ocorrem erros no backend. Al\u00e9m disso, registo o n\u00famero da liga\u00e7\u00e3o e o n\u00famero de pedidos efetuados atrav\u00e9s da liga\u00e7\u00e3o atual do cliente, para identificar correla\u00e7\u00f5es.<\/p>\n\n<pre><code>log_format upstream_timing '$remote_addr - $host \"$request\" '\n 'up=$upstream_addr '\n 'sc=$status usc=$upstream_status '\n                           'cc=$connection cr=$connection_requests '\n 'tc=$upstream_connect_time '\n 'th=$upstream_header_time '\n 'tr=$upstream_response_time';\n\naccess_log \/var\/log\/nginx\/access_upstream.log upstream_timing;\n<\/code><\/pre>\n\n<p>Al\u00e9m disso, utilizo os pontos finais de estado e as estat\u00edsticas de socket do SO. Um estado saud\u00e1vel caracteriza-se por: uma taxa de liga\u00e7\u00e3o ao backend em descida, um \u00abupstream_connect_time\u00bb mais curto, tempos de resposta est\u00e1veis e quase nenhuma reinicializa\u00e7\u00e3o de liga\u00e7\u00e3o. Os desvios indicam quase sempre limites de tempo mal ajustados ou pools demasiado pequenos ou demasiado grandes.<\/p>\n\n<h2>Estrat\u00e9gia de implementa\u00e7\u00e3o e ajustes com baixo risco<\/h2>\n\n<p>Procedo de forma iterativa: pequenos passos, medir, ajustar. Primeiro, ativo o Keepalive de forma moderada; depois, ajusto os tempos de espera e o n\u00famero de pedidos por liga\u00e7\u00e3o. Aplico as altera\u00e7\u00f5es atrav\u00e9s de uma atualiza\u00e7\u00e3o da p\u00e1gina, sem interromper as liga\u00e7\u00f5es ativas. Desta forma, o risco mant\u00e9m-se baixo e os efeitos podem ser atribu\u00eddos com clareza.<\/p>\n\n<pre><code># Validar altera\u00e7\u00f5es e carregar sem tempo de inatividade\nnginx -t &amp;&amp; nginx -s reload\n<\/code><\/pre>\n\n<p>Quando tenho v\u00e1rios upstreams em funcionamento, fa\u00e7o o ajuste de cada um deles sucessivamente, come\u00e7ando pelo caminho mais cr\u00edtico. A cada etapa \u00e9 atribu\u00edda uma janela de observa\u00e7\u00e3o, para que os padr\u00f5es nas m\u00e9tricas se tornem claramente vis\u00edveis. S\u00f3 depois \u00e9 que aumentei ou reduzo os valores.<\/p>\n\n<h2>Resumo conciso sobre o teu proxy reverso<\/h2>\n\n<p>Utilizo o HTTP\/1.1, esvazio o cabe\u00e7alho \u00abConnection\u00bb e defino o tamanho do pool com base no n\u00famero de pedidos simult\u00e2neos, e n\u00e3o no RPS; isso contribui para a <strong>Desempenho<\/strong>. Com as op\u00e7\u00f5es `keepalive_requests` e `keepalive_timeout`, mantenho as liga\u00e7\u00f5es ativas e evito surpresas causadas por sockets desatualizados. A monitoriza\u00e7\u00e3o mostra se o valor de `upstream_connect_time` tende para zero e se a taxa de liga\u00e7\u00f5es ao backend est\u00e1 a diminuir. Em caso de erros, verifico primeiro a vers\u00e3o do protocolo, a transmiss\u00e3o de cabe\u00e7alhos, os limites de tempo e o tamanho do pool. Assim, o teu proxy NGINX mant\u00e9m-se est\u00e1vel sob carga elevada <strong>reativo<\/strong> e previs\u00edvel.<\/p>","protected":false},"excerpt":{"rendered":"<p>Aprenda a configurar da melhor forma o NGINX Upstream Keepalive no bloco \u00abnginx upstream\u00bb, para tornar o seu proxy inverso significativamente mais eficiente.<\/p>","protected":false},"author":1,"featured_media":21606,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-21613","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-plesk-webserver-plesk-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"110","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":null,"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"NGINX Upstream","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"21606","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21613","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/comments?post=21613"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21613\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/21606"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=21613"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=21613"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=21613"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}