curl -N kann einem Proxy nicht sagen, dass er die Pufferung beenden soll

curl -N oder --no-buffer deaktiviert die Pufferung des Ausgabestreams von curl. Es kann helfen, verzögerte Ausgaben zu diagnostizieren, ohne die Pufferungsrichtlinie des Proxys oder Servers zu ändern.

curl --proxy http://proxy.example:8080 --noproxy '' --no-buffer --max-time 30 https://example.com/stream

Für einen Vergleich über einen öffentlichen Proxy wählen Sie einen HTTP-Endpunkt aus der HTTP-Proxy-Liste. Verwenden Sie Ihre tatsächliche Stream-URL und wählen Sie das beabsichtigte Limit. Die leere Bypass-Liste hält diesen Vergleich auf der gewählten Proxy-Route.

Ankunft, Dekodierung und Anzeige

Ein Server kann schrittweise Bytes erzeugen, ein Vermittler kann sie sammeln, eine Clientbibliothek kann den vollständigen Body lesen, und ein Browser kann die Darstellung verzögern. Vergleichen Sie die ersten nutzbaren Bytes und den weiteren Fortschritt dort, wo Sie den Pfad kontrollieren. Zeichenzeit und Gesamtdauer des Servers bestimmen nicht, wann der Body ankommt.

Prüfen Sie in Guzzle Streaming und Body-Verbrauch getrennt. Komprimierung fügt eine Dekodierungsstufe hinzu. Eine Änderung des Zeitpunkts, zu dem dekodierte Ausgabe erscheint, belegt für sich genommen nicht, dass ein Proxy die puffernde Komponente ist.

Was der Vermittler sieht

Ein undurchsichtiger CONNECT-Proxy kann innere HTTPS-Antworten nicht als gewöhnliches HTTP parsen. Ein autorisierter TLS-Inspektionsdienst hat eine andere Sichtbarkeit, daher beweist HTTPS allein nicht, dass keine Inspektion stattfindet.

Sobald die Wartestufe identifiziert ist, verwenden Sie die von dieser Komponente unterstützten Streaming-Steuerungen. Reverse-Proxy-Richtlinien gelten nicht automatisch für einen Forward-Proxy; das Ausgabeflag von curl ändert nur seinen eigenen Teil des Pfads.