{"id":21459,"date":"2026-09-16T15:03:59","date_gmt":"2026-09-16T13:03:59","guid":{"rendered":"https:\/\/webhosting.de\/nginx-keepalive-requests-optimieren-webserver-performance-tuning\/"},"modified":"2026-09-16T15:03:59","modified_gmt":"2026-09-16T13:03:59","slug":"otimizar-os-pedidos-keepalive-do-nginx-ajuste-do-desempenho-do-servidor-web","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/nginx-keepalive-requests-optimieren-webserver-performance-tuning\/","title":{"rendered":"Otimizar os pedidos Keepalive do NGINX: o m\u00e1ximo desempenho do servidor web atrav\u00e9s de um ajuste espec\u00edfico"},"content":{"rendered":"<p>Com <strong>nginx keepalive<\/strong> Reduzo os custos de estabelecimento de liga\u00e7\u00e3o, diminuo os handshakes e acelero sensivelmente os tempos de resposta. Tempos de espera ajustados de forma espec\u00edfica, limites de pedidos por liga\u00e7\u00e3o e sockets upstream reutilizados proporcionam ganhos de desempenho mensur\u00e1veis sem necessidade de novo hardware.<\/p>\n\n<h2>Pontos centrais<\/h2>\n\n<ul>\n  <li><strong>Intervalos<\/strong> Escolher de forma sensata: o tempo de inatividade deve ser t\u00e3o curto quanto necess\u00e1rio e t\u00e3o longo quanto \u00fatil.<\/li>\n  <li><strong>Pedidos<\/strong> Limitar por liga\u00e7\u00e3o: Sockets duradouros, sem travamentos.<\/li>\n  <li><strong>Grupos a montante<\/strong> Ativar: liga\u00e7\u00f5es persistentes ao backend por trabalhador.<\/li>\n  <li><strong>Trabalhador<\/strong> e ajustar as liga\u00e7\u00f5es: slots suficientes para clientes inativos e ativos.<\/li>\n  <li><strong>Monitoriza\u00e7\u00e3o<\/strong> Estabelecer: monitorizar a taxa de liga\u00e7\u00e3o, a lat\u00eancia e os erros.<\/li>\n<\/ul>\n\n<h2>NGINX Keepalive: Efeitos e custos<\/h2>\n\n<p>Mantenho as liga\u00e7\u00f5es TCP abertas de forma deliberada, porque <strong>Apertos de m\u00e3o<\/strong> s\u00e3o dispendiosas e predominam em muitas pequenas solicita\u00e7\u00f5es. Os sockets persistentes n\u00e3o s\u00f3 poupam RTTs, como tamb\u00e9m uniformizam a carga da CPU, uma vez que a criptografia para o TLS \u00e9 executada com menos frequ\u00eancia. No entanto, cada liga\u00e7\u00e3o aberta ocupa <strong>Recursos<\/strong>, como descritores de ficheiros e buffers, que tenho de manter sob controlo. O segredo est\u00e1 no equil\u00edbrio: reutiliza\u00e7\u00e3o suficiente para garantir a velocidade, e recursos suficientes para estabelecer novas liga\u00e7\u00f5es em picos de tr\u00e1fego. Quem conseguir equilibrar estes aspetos consegue valores de TTFB consistentemente baixos e uma experi\u00eancia de utilizador r\u00e1pida.<\/p>\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-keepalive-optimierung-4271.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>HTTP\/2 e HTTP\/3: o multiplexing aliado ao keepalive<\/h2>\n\n<p>Com <strong>HTTP\/2<\/strong> e <strong>HTTP\/3<\/strong> O n\u00famero de liga\u00e7\u00f5es necess\u00e1rias por cliente diminui, uma vez que v\u00e1rios fluxos passam por uma \u00fanica linha. No entanto, o Keepalive continua a ser relevante: essa liga\u00e7\u00e3o deve permanecer aberta de forma fi\u00e1vel; caso contr\u00e1rio, a vantagem da multiplexa\u00e7\u00e3o perde-se devido \u00e0s frequentes reconex\u00f5es.<\/p>\n<p>Presto aten\u00e7\u00e3o aos par\u00e2metros de inatividade espec\u00edficos para protocolos modernos e certifico-me de que os valores correspondem aos meus tempos limite do cliente. Para os testes, come\u00e7o com valores moderados e vou aumentando, \u00e0 medida que a carga se mant\u00e9m est\u00e1vel, at\u00e9 que a taxa de reconex\u00e3o diminua e as lat\u00eancias se mantenham constantes.<\/p>\n\n<pre><code>http {\n    # HTTP\/2: tempo de inatividade para fluxos n\u00e3o utilizados, mas abertos\n    http2_idle_timeout 60s;\n\n    # HTTP\/3\/QUIC: l\u00f3gica semelhante para liga\u00e7\u00f5es baseadas em UDP\n    http3_idle_timeout 60s;\n\n    # A retomada de sess\u00e3o TLS reduz os custos do handshake em novas liga\u00e7\u00f5es\n    ssl_session_cache shared:SSL:50m;\n    ssl_session_timeout 1d;\n    ssl_session_tickets off;\n}\n<\/code><\/pre>\n\n<p>O multiplexing reduz o n\u00famero necess\u00e1rio de liga\u00e7\u00f5es TCP\/QUIC paralelas, mas n\u00e3o a import\u00e2ncia da <strong>tempos de espera corretos<\/strong>. Quem utiliza o HTTP\/2\/3 pode, muitas vezes, definir os tempos de espera do cliente de forma um pouco mais generosa, uma vez que muitos recursos pequenos circulam pelo mesmo canal. Importante: continuar a ser mensur\u00e1vel <em>Tempo para o primeiro byte<\/em>, taxas de erro e fluxos abertos por liga\u00e7\u00e3o.<\/p>\n\n<h2>Configurar corretamente o Client-Keepalive<\/h2>\n\n<p>No caso dos clientes de navegador, controlo a reutiliza\u00e7\u00e3o atrav\u00e9s de <strong>tempo de espera de keepalive<\/strong> e <strong>keepalive_requests<\/strong>, para que as liga\u00e7\u00f5es permane\u00e7am ativas durante tempo suficiente sem ficarem bloqueadas indefinidamente. Como ponto de partida, utilizo um tempo de espera de 30 a 60 segundos e 100 a 300 pedidos por liga\u00e7\u00e3o; depois, vou ajustando com base nas m\u00e9tricas. Este artigo fornece uma an\u00e1lise detalhada <a href=\"https:\/\/webhosting.de\/pt\/http-keepalive-timeout-configuracao-do-desempenho-do-servidor\/\">Guia sobre o tempo de espera do Keepalive<\/a>, que explica o impacto na lat\u00eancia e nos recursos do servidor. Os tempos de espera mais curtos s\u00e3o adequados para um grande n\u00famero de chamadas curtas, enquanto os intervalos mais longos s\u00e3o \u00fateis para acessos peri\u00f3dicos \u00e0 API. Para come\u00e7ar, defino valores predefinidos claros e avalio o impacto nas liga\u00e7\u00f5es abertas, bem como nos padr\u00f5es de erros.<\/p>\n\n<pre><code>http {\n    # Liga\u00e7\u00f5es inativas com o cliente\n    keepalive_timeout 60s;\n    # Limite m\u00e1ximo de pedidos por liga\u00e7\u00e3o TCP\n    keepalive_requests 200;\n\n    # Opcional: desativar o Keep-Alive para determinados clientes (erros herdados)\n    # keepalive_disable msie6;\n}\n<\/code><\/pre>\n\n<h2>Keepalive a montante no proxy reverso<\/h2>\n\n<p>Entre o NGINX e as aplica\u00e7\u00f5es de backend, utilizo sockets upstream persistentes, porque a liga\u00e7\u00e3o ao PHP-FPM, ao Node.js ou aos servi\u00e7os Python tamb\u00e9m <strong>Lat\u00eancia<\/strong> custa. Para tal, ativo no pool upstream um n\u00famero adequado de liga\u00e7\u00f5es reutiliz\u00e1veis por trabalhador. \u00c9 importante utilizar HTTP\/1.1 na resposta e um cabe\u00e7alho \u201eConnection\u201c vazio; caso contr\u00e1rio, o pedido \u00abclose\u00bb do cliente interrompe a persist\u00eancia do backend. Baseio-me no n\u00famero de pedidos simult\u00e2neos e configuro o pool de forma a que quase n\u00e3o ocorram novas liga\u00e7\u00f5es. Desta forma, o tempo de liga\u00e7\u00e3o do backend diminui e toda a cadeia proporciona um desempenho mais \u00e1gil <strong>Respostas<\/strong>.<\/p>\n\n<pre><code>upstream backend {\n    server 127.0.0.1:9000;\n    keepalive 64; # N\u00famero de liga\u00e7\u00f5es persistentes upstream por trabalhador\n}\n\nserver {\n    location \/ {\n proxy_pass http:\/\/backend;\n        proxy_http_version 1.1;\n proxy_set_header Connection \"\";\n # Keepalive TCP para sockets de upstream ao n\u00edvel do sistema operativo\n proxy_socket_keepalive on;\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_optimierung_miniature_4891.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Dimensionamento do conjunto e or\u00e7amento de liga\u00e7\u00f5es<\/h2>\n\n<p>Calculo os pools de forma realista: o n\u00famero de liga\u00e7\u00f5es persistentes a montante resulta de <strong>worker_processes \u00d7 keepalive<\/strong> por upstream. Quem utilizar 8 workers e um keepalive de 64 mant\u00e9m abertos at\u00e9 512 sockets por upstream \u2013 por inst\u00e2ncia. Atr\u00e1s de um balanceador de carga ou com v\u00e1rios destinos upstream, esse n\u00famero pode aumentar rapidamente.<\/p>\n<p>O meu valor-alvo: sockets abertos suficientes para que a maior parte dos pedidos <em>sem o novo Connect<\/em> \u00e9 atendida, mas ainda h\u00e1 margem para picos. Observo a m\u00e9trica \u201enovas liga\u00e7\u00f5es de upstream por segundo\u201c e vou reduzindo-a at\u00e9 que novos aumentos no tamanho do pool deixem de trazer melhorias significativas na lat\u00eancia.<\/p>\n<p>Tamb\u00e9m tenho em conta <strong>Equidade<\/strong>: As piscinas demasiado grandes podem prejudicar os clientes rec\u00e9m-chegados, uma vez que os slots dos trabalhadores ocupam liga\u00e7\u00f5es inativas. Um limite moderado, acompanhado de uma monitoriza\u00e7\u00e3o ativa, \u00e9 geralmente mais r\u00e1pido do que valores m\u00e1ximos definidos por suposi\u00e7\u00e3o.<\/p>\n\n<h2>Ajuste fino: tempos limite e limites de pedidos<\/h2>\n\n<p>Combino o tempo de espera e o limite de pedidos de forma a que as liga\u00e7\u00f5es sejam efetivamente reutilizadas, sem que isso leve ao <strong>Esquiador de fundo<\/strong> . Valores elevados em ambos os eixos minimizam as liga\u00e7\u00f5es, mas aumentam o risco de sockets ficarem pendentes em caso de problemas de rede. Valores baixos garantem liga\u00e7\u00f5es recentes, mas implicam handshakes adicionais. Vou avan\u00e7ando aos poucos, observando os erros e ajustando periodicamente. A tabela seguinte apresenta intervalos iniciais adequados para diferentes padr\u00f5es de utiliza\u00e7\u00e3o e fornece uma vis\u00e3o compacta <strong>Orienta\u00e7\u00e3o<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Cen\u00e1rio<\/th>\n      <th>tempo de espera de keepalive<\/th>\n      <th>keepalive_requests<\/th>\n      <th>Nota<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Muitas visualiza\u00e7\u00f5es de p\u00e1ginas curtas<\/td>\n      <td>10\u201330 s<\/td>\n      <td>100-300<\/td>\n      <td>Reutiliza\u00e7\u00e3o r\u00e1pida, baixo consumo em modo inativo<\/td>\n    <\/tr>\n    <tr>\n      <td>Site t\u00edpico<\/td>\n      <td>60\u2013120 s<\/td>\n      <td>200\u2013400<\/td>\n      <td>Um bom n\u00edvel m\u00e9dio para Assets e HTML<\/td>\n    <\/tr>\n    <tr>\n      <td>API com chamadas peri\u00f3dicas<\/td>\n      <td>60\u2013120 s<\/td>\n      <td>300\u20131000<\/td>\n      <td>Maior taxa de reutiliza\u00e7\u00e3o para os clientes<\/td>\n    <\/tr>\n    <tr>\n      <td>Servi\u00e7os internos \/ Gateways<\/td>\n      <td>30\u201390 s<\/td>\n      <td>500\u20131000+<\/td>\n      <td>A consist\u00eancia \u00e9 mais importante do que um n\u00famero m\u00ednimo de liga\u00e7\u00f5es<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Ajuste dos trabalhadores e liga\u00e7\u00f5es<\/h2>\n\n<p>Coloquei <strong>processos_trabalhadores<\/strong> em \u00abauto\u00bb ou no n\u00famero de n\u00facleos da CPU e planeia o suficiente <strong>liga\u00e7\u00f5es_trabalhadores<\/strong> porque os sockets inativos ocupam slots. Limites demasiado baixos impedem novas aceita\u00e7\u00f5es, apesar de ainda haver capacidade de CPU dispon\u00edvel. Quem utiliza pools de keepalive elevadas precisa de descritores e slots de eventos suficientes por cada worker. Uma boa introdu\u00e7\u00e3o \u00e9 fornecida por \u201e<a href=\"https:\/\/webhosting.de\/pt\/nginx-ligacoes-dos-workers-escalabilidade-milhares-de-pedidos-aumento-do-trafego\/\">Escalar as liga\u00e7\u00f5es dos trabalhadores<\/a>\u201c, que explica as rela\u00e7\u00f5es entre eventos, liga\u00e7\u00f5es e carga. Valores cuidadosamente definidos garantem que a reutiliza\u00e7\u00e3o em modo inativo e as novas liga\u00e7\u00f5es possam coexistir.<\/p>\n\n<pre><code>worker_processes auto;\n\nevents {\n    worker_connections 4096;\n    # Opcional: a op\u00e7\u00e3o \u00abreuseport\u00bb pode melhorar a distribui\u00e7\u00e3o ao n\u00edvel do kernel\n    # multi_accept on;\n}\n\nhttp {\n    keepalive_timeout 60s;\n    keepalive_requests 200;\n\n upstream backend {\n server 127.0.0.1:9000;\n keepalive 64;\n    }\n}\n<\/code><\/pre>\n\n<h2>Otimiza\u00e7\u00e3o do sistema operativo e dos sockets<\/h2>\n\n<p>Estou a verificar os limites do sistema para que o Keepalive possa atingir o seu pleno potencial. Um n\u00famero insuficiente de descritores ou filas de sockets muito curtas provocam <strong>estrangulamentos artificiais<\/strong>. Para al\u00e9m do ulimit e do worker_rlimit_nofile, os limites do kernel s\u00e3o fundamentais.<\/p>\n\n<pre><code># Valores de sysctl exemplificativos (ajustar com cuidado e ap\u00f3s realizar testes)\nfs.file-max = 1000000\nnet.core.somaxconn = 65535\nnet.core.netdev_max_backlog = 16384\nnet.ipv4.ip_local_port_range = 1024 65000\nnet.ipv4.tcp_fin_timeout = 15\nnet.ipv4.tcp_tw_reuse = 1\nnet.ipv4.tcp_max_syn_backlog = 262144\n<\/code><\/pre>\n\n<p>Calibro estes valores em fun\u00e7\u00e3o do ambiente: muitas liga\u00e7\u00f5es de curta dura\u00e7\u00e3o beneficiam de um intervalo de portas mais alargado e de tempos FIN\/TIME_WAIT mais curtos. No caso do keepalive a montante, reduzo <em>Neuconnects<\/em>, o que reduz as press\u00f5es do TIME_WAIT. Al\u00e9m disso, tenho em conta <strong>NAT<\/strong>- Equipamentos entre o proxy e o backend: tempos de espera em inatividade demasiado agressivos na rede cortam as liga\u00e7\u00f5es de forma imprevis\u00edvel. Um limite moderado de pedidos por socket e keepalives TCP (<code>proxy_socket_keepalive on;<\/code>) evitam liga\u00e7\u00f5es \u201eestagnadas\u201c.<\/p>\n\n<h2>Definir corretamente o cabe\u00e7alho e a vers\u00e3o HTTP<\/h2>\n\n<p>Presto aten\u00e7\u00e3o a <strong>HTTP\/1.1<\/strong> para o backend, porque o Upstream-Keepalive s\u00f3 funciona assim. Al\u00e9m disso, removo o controlo ativo das liga\u00e7\u00f5es atrav\u00e9s do cabe\u00e7alho, para que o NGINX gere a persist\u00eancia de forma aut\u00f3noma. Do lado do cliente, deixo o Keep-Alive a funcionar de acordo com a norma e limito o tempo de vida atrav\u00e9s do timeout e do limite de pedidos. Al\u00e9m disso, verifico os timeouts de inatividade do backend e defino-os ligeiramente acima dos valores do NGINX, para evitar erros de reinicializa\u00e7\u00e3o. Cabe\u00e7alhos bem definidos garantem a <strong>Reutiliza\u00e7\u00e3o<\/strong> sem encerramentos indesejados.<\/p>\n\n<pre><code>Exemplo #: Localiza\u00e7\u00e3o do proxy com cabe\u00e7alhos corretos\nlocation \/api\/ {\n    proxy_pass http:\/\/backend;\n    proxy_http_version 1.1;\n    proxy_set_header Connection \"\";\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-keepalive-optimization-7123.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Diferencia\u00e7\u00e3o: HTTP Keep-Alive vs. TCP Keep-Alive<\/h2>\n\n<p>Fa\u00e7o uma distin\u00e7\u00e3o rigorosa entre <strong>HTTP Keep-Alive<\/strong> (v\u00e1rias solicita\u00e7\u00f5es HTTP por liga\u00e7\u00e3o) e <strong>TCP-Keepalive<\/strong> (Testes ao n\u00edvel do sistema operativo para detetar terminais inativos). Controlo o HTTP Keep-Alive com <code>tempo de espera de keepalive<\/code> e <code>keepalive_requests<\/code>, enquanto os keepalives do TCP, dependendo da pilha, podem ser de <code>proxy_socket_keepalive on;<\/code> e os par\u00e2metros do sistema. Para backends que utilizam redes inst\u00e1veis, ativo os keepalives do TCP para limpar mais rapidamente os sockets bloqueados.<\/p>\n\n<h2>Aplica\u00e7\u00f5es de longa dura\u00e7\u00e3o e casos especiais: WebSockets, SSE, gRPC<\/h2>\n\n<p>WebSockets e eventos enviados pelo servidor s\u00e3o <strong>Esquiador de fundo<\/strong>, que mant\u00eam uma liga\u00e7\u00e3o aberta durante muito tempo \u2013 neste caso, a Reuse cl\u00e1ssica desempenha um papel secund\u00e1rio. Eu garanto que haja <code>tempo_limite_de_leitura_proxy<\/code> e protege-me com <code>tempo_limite_de_envio<\/code> contra <em>Slowloris<\/em>-Efeitos. No caso do gRPC (baseado em HTTP\/2), aplicam-se as considera\u00e7\u00f5es relativas \u00e0 multiplexa\u00e7\u00e3o; configuro os tempos de espera de inatividade de forma a que os fluxos n\u00e3o sejam encerrados desnecessariamente.<\/p>\n\n<pre><code>location \/ws\/ {\n    proxy_pass http:\/\/backend;\n    proxy_http_version 1.1;\n    proxy_set_header Upgrade $http_upgrade;\n    proxy_set_header Connection \"upgrade\";\n    proxy_read_timeout 300s;\n    send_timeout 30s;\n}\n<\/code><\/pre>\n\n<h2>Monitoriza\u00e7\u00e3o e m\u00e9tricas<\/h2>\n\n<p>Mido o sucesso atrav\u00e9s de indicadores como a taxa de novas liga\u00e7\u00f5es upstream, <strong>upstream_connect_time<\/strong> e a percentagem de liga\u00e7\u00f5es abertas por cada worker. A diminui\u00e7\u00e3o das taxas de liga\u00e7\u00e3o, com o n\u00famero de pedidos a manter-se est\u00e1vel ou a aumentar, indica uma reutiliza\u00e7\u00e3o bem-sucedida. Tempos de espera ou reinicializa\u00e7\u00f5es de liga\u00e7\u00e3o anormais sinalizam tempos de espera contradit\u00f3rios entre o NGINX e o backend. Al\u00e9m disso, observo a mem\u00f3ria, os descritores de ficheiros e as filas de eventos sob carga. Quem verifica regularmente identifica tend\u00eancias numa fase precoce e evita custos elevados <strong>Falhas<\/strong>.<\/p>\n\n<h2>Melhorias no registo para uma maior transpar\u00eancia na reutiliza\u00e7\u00e3o<\/h2>\n\n<p>Para obter mais informa\u00e7\u00f5es, vou adicionar detalhes sobre as liga\u00e7\u00f5es ao registo de acesso. Assim, consigo perceber com que frequ\u00eancia uma liga\u00e7\u00e3o TCP \u00e9 reutilizada e como evoluem os tempos de liga\u00e7\u00e3o.<\/p>\n\n<pre><code>log_format keepalive_fmt\n  '$remote_addr $host \"$request\" $status $body_bytes_sent '\n  '$request_time $upstream_connect_time '\n  'conn:$connection reqs:$connection_requests';\n\naccess_log \/var\/log\/nginx\/access_keepalive.log keepalive_fmt;\n<\/code><\/pre>\n\n<p>Estou a analisar os valores da mediana e dos percentis P95\/P99 de <em>upstream_connect_time<\/em> bem como a distribui\u00e7\u00e3o de <em>$ pedidos de liga\u00e7\u00e3o<\/em>. O aumento do n\u00famero de repeti\u00e7\u00f5es, com uma lat\u00eancia est\u00e1vel, significa que os conjuntos e os tempos limite foram escolhidos de forma adequada.<\/p>\n\n<h2>Obst\u00e1culos e solu\u00e7\u00f5es t\u00edpicos<\/h2>\n\n<p>As pilhas demasiado grandes ocupam as ranhuras de liga\u00e7\u00e3o, enquanto novos clientes ficam \u00e0 espera; por isso, mantenho os tamanhos moderados e vou ajustando. Tempos de espera em inatividade diferentes entre o proxy e o backend provocam reinicializa\u00e7\u00f5es; por isso, defino o backend com um valor ligeiramente superior ao <strong>NGINX<\/strong>. Um \u201eConnection: close\u201c esquecido no cabe\u00e7alho do proxy interrompe a persist\u00eancia; por isso, esvazio o cabe\u00e7alho de forma sistem\u00e1tica. A negocia\u00e7\u00e3o TLS pode sobrecarregar a CPU quando h\u00e1 muitas novas liga\u00e7\u00f5es, o que atenuei aumentando a taxa de reutiliza\u00e7\u00e3o. Em caso de falhas espor\u00e1dicas na rede, um limite moderado de pedidos por socket ajuda a garantir que as antigas <strong>Sess\u00f5es<\/strong> n\u00e3o viveremos para sempre.<\/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_optimierung_4723.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Configura\u00e7\u00f5es orientadas para a pr\u00e1tica<\/h2>\n\n<p>Para sites com muito tr\u00e1fego, opto por um tempo de espera curto e um limite de pedidos m\u00e9dio-alto, para que os recursos funcionem de forma eficiente. No caso de APIs com chamadas recorrentes, aumentei o limite para reduzir ainda mais os handshakes TCP e TLS. Dimensiono os pools de upstream com base no paralelismo esperado e testo com tr\u00e1fego realista. Cada ambiente comporta-se de forma diferente, por isso verifico a lat\u00eancia e os padr\u00f5es de erros ap\u00f3s quaisquer altera\u00e7\u00f5es. Dois exemplos ilustram isto: <strong>Valores iniciais<\/strong>, que depois aperfei\u00e7oo com m\u00e9tricas.<\/p>\n\n<pre><code># Cen\u00e1rio 1: Site com elevado tr\u00e1fego\nhttp {\n    keepalive_timeout 30s;\n    keepalive_requests 300;\n\n upstream app {\n server 127.0.0.1:8080;\n        keepalive 32;\n    }\n\n server {\n listen 443 ssl http2;\n Acompanhar o tempo de inatividade HTTP\/2 (#)\n http2_idle_timeout 45s;\n    }\n}\n<\/code><\/pre>\n\n<pre><code># Cen\u00e1rio 2: API com chamadas peri\u00f3dicas\nhttp {\n    keepalive_timeout 75s;\n    keepalive_requests 1000;\n\n    upstream api_backend {\n server 127.0.0.1:9001;\n keepalive 64;\n    }\n\n    server {\n listen 443 ssl http2;\n # Janela de inatividade ligeiramente mais longa para chamadas recorrentes\n http2_idle_timeout 75s;\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\/serverraum-nginx-3721.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Lista de verifica\u00e7\u00e3o para a otimiza\u00e7\u00e3o iterativa<\/h2>\n\n<p>Come\u00e7o por fazer uma an\u00e1lise da situa\u00e7\u00e3o atual: os padr\u00f5es de tr\u00e1fego, os tempos de resposta e a taxa de erros ditam o ritmo. Em seguida, defino o tempo limite do cliente e o limite de pedidos com valores iniciais s\u00f3lidos e ativo os conjuntos de servidores a montante. Defino os tempos limite de inatividade do backend um pouco mais altos do que no NGINX, para evitar que ocorram <strong>Reinicializa\u00e7\u00f5es<\/strong> ocorrer. Em seguida, monitorizo as taxas de liga\u00e7\u00e3o, o tempo de liga\u00e7\u00e3o e os sockets abertos por trabalhador. Quem quiser aprofundar o tema do grau de reutiliza\u00e7\u00e3o encontrar\u00e1 sugest\u00f5es sobre <a href=\"https:\/\/webhosting.de\/pt\/ligacao-http-reutilizacao-keepalive-otimizacao-serverperf-boost\/\">Reutiliza\u00e7\u00e3o de liga\u00e7\u00f5es<\/a> e limites m\u00e1ximos razo\u00e1veis.<\/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_opt_5731.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Diagn\u00f3stico adicional: incompatibilidades e comportamento temporal<\/h2>\n\n<p>Quando as liga\u00e7\u00f5es parecem interromper-se \u201esem motivo aparente\u201c, procuro <strong>Incompatibilidades<\/strong> na cadeia: inatividade do cliente vs. tempo de espera do NGINX vs. inatividade do backend e NAT\/gateways interm\u00e9dios. Aumento ligeiramente o tempo de espera do backend para um valor ligeiramente superior ao do NGINX, verifico os c\u00f3digos de reinicializa\u00e7\u00e3o no registo de erros e observo se <em>upstream_connect_time<\/em> Mostra picos. Muitas vezes, basta uma pequena margem de seguran\u00e7a (por exemplo, +10\u201320%) no tempo limite do backend para eliminar os rein\u00edcios.<\/p>\n<p>Al\u00e9m disso, tenho em conta que \u201e<em>abra\u00e7o demorado<\/em>\u201cFases de encerramento: ao encerrar uma liga\u00e7\u00e3o, o NGINX permite que os dados recebidos sejam transmitidos durante um breve per\u00edodo, o que ocupa recursos dos workers. Um n\u00famero muito elevado de encerramentos simult\u00e2neos pode bloquear eventos. Nesses casos, calibro as janelas de tempo de encerramento e mantenho o n\u00famero total de liga\u00e7\u00f5es abertas equilibrado, definindo valores adequados para o keepalive.\u00bb.<\/p>\n\n<h2>Resumo: O Keepalive como alavanca de desempenho<\/h2>\n\n<p>Utilizo o Keepalive de forma seletiva, porque reduz os custos de estabelecimento de liga\u00e7\u00e3o, diminui a lat\u00eancia e alivia a carga da CPU. A combina\u00e7\u00e3o de um tempo de espera adequado, um limite de pedidos bem definido e conjuntos de servidores upstream adequados traz benef\u00edcios percet\u00edveis <strong>Velocidade<\/strong>. Sem monitoriza\u00e7\u00e3o, o potencial fica por explorar; por isso, analiso continuamente os indicadores e ajusto os valores passo a passo. Quem precisar de reservas adicionais deve prestar aten\u00e7\u00e3o ao n\u00famero de workers, aos slots de liga\u00e7\u00e3o e ao tratamento correto dos cabe\u00e7alhos. Configura\u00e7\u00f5es profissionais, por exemplo, em <strong>webhoster.de<\/strong>, tiram o m\u00e1ximo partido destes recursos e prestam servi\u00e7os r\u00e1pidos e fi\u00e1veis.<\/p>","protected":false},"excerpt":{"rendered":"<p>Aprenda a otimizar os pedidos Keepalive do NGINX para aumentar significativamente o desempenho dos seus servidores web. Com configura\u00e7\u00f5es pr\u00e1ticas para keepalive_timeout, keepalive_requests, Upstream-Keepalive e ajuste dos workers \u2013 incluindo um enfoque no Keepalive do NGINX como fator-chave.<\/p>","protected":false},"author":1,"featured_media":21452,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-21459","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":[],"_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 keepalive","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":"21452","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21459","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=21459"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21459\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/21452"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=21459"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=21459"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=21459"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}