curl -N não consegue dizer a um proxy para parar de armazenar em buffer
Localize o buffering no cliente, no intermediário ou no lado da renderização sem presumir que a opção de saída do curl altera todo o caminho da resposta.
curl -N, ou --no-buffer, desativa o buffering do fluxo de saída do curl. Isso pode ajudar a diagnosticar saída atrasada sem alterar a política de buffering do proxy ou do servidor.
curl --proxy http://proxy.example:8080 --noproxy '' --no-buffer --max-time 30 https://example.com/streamPara uma comparação por proxy público, escolha um endpoint HTTP da lista de proxies HTTP. Use a URL real do seu fluxo e escolha o limite pretendido. A lista de desvio vazia mantém essa comparação na rota do proxy selecionado.
Chegada, decodificação e exibição
Um servidor pode gerar bytes incrementais, um intermediário pode reuni-los, uma biblioteca cliente pode ler o corpo completo e um navegador pode adiar a renderização. Compare os primeiros bytes úteis e o progresso seguinte onde você controla o caminho. O tempo de pintura e a duração total do servidor não identificam quando o corpo chega.
No Guzzle, verifique streaming e consumo do corpo separadamente. A compressão adiciona uma etapa de decodificação. Uma mudança no momento em que a saída decodificada aparece não identifica por si só um proxy como o componente de buffering.
O que o intermediário vê
Um proxy CONNECT opaco não consegue analisar respostas HTTPS internas como HTTP comum. Um serviço de inspeção TLS autorizado tem visibilidade diferente, portanto HTTPS sozinho não prova a ausência de inspeção.
Depois de identificar a etapa de espera, use os controles de streaming suportados por esse componente. Diretivas de proxy reverso não se aplicam automaticamente a um proxy direto; a opção de saída do curl altera apenas sua própria parte do caminho.