APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Começa pela fase que falhou e pela evidência que a sustenta. 502 indica resposta inválida recebida por um gateway do upstream; 504 indica ausência de resposta atempada. Nenhum código, isoladamente, prova deadlock de base de dados ou falha DNS. Correlaciona identificador, endpoint, tempo total e tempos upstream com os logs relevantes. Evita guardar tokens e corpos integrais por omissão: o identificador e campos delimitados podem permitir a comparação necessária. Um 429 com Retry-After orienta espera e redução de pressão; limita tentativas e concorrência de acordo com o contrato e orçamento. A tentativa seguinte não tem sucesso garantido só por ter esperado.
Aplicação guiada
Interpreta a definição de cada métrica. Numa ligação HTTPS nova e direta, sem proxy ou redirecionamento, time_connect e time_appconnect de curl são marcos cumulativos. Se valem 0,15 e 0,35 segundos, a diferença de 0,20 aproxima a fase TLS após TCP nesse contexto. Reutilização de ligação e outros percursos exigem cuidado adicional. Em NGINX, proxy_read_timeout limita intervalos entre leituras, não toda a duração da resposta. Num caso fictício, o upstream fica silencioso 75 segundos e o cliente desiste aos 70. Aumentar só o proxy de 60 para 90 desloca a falha. Investiga a regressão e define limites coerentes de ponta a ponta, mantendo critérios de recuperação e validação funcional.
Um upstream de 75 s excede um cliente com prazo de 70 s, mesmo que o proxy espere 90 s.
Armadilhas comuns
Somar marcos cumulativos; confundir intervalo com duração total; 504 como causa identificada; retries sem orçamento.
Tópicos relacionados: O pedido e a representação pretendida · Métodos, estados e repetição controlada · Cache, variantes e validação
Usa métricas com definição conhecida e valida o orçamento completo do pedido.
Referência: NGINX upstream response timing · DR HTTP/HTTPS 2026-09; HTTP RFCs 9110–9114; selected TLS 1.3 and NGINX/curl guidance