curl -N не може да каже на прокси да спре буферирането
Открийте къде е буферирането — при клиента, посредника или страната на изобразяване — без да предполагате, че флагът за изход на curl променя целия път на отговора.
curl -N, или --no-buffer, изключва буферирането на изходния поток на curl. Това може да помогне за диагностициране на забавения изход, без да променя политиката за буфериране на проксито или сървъра.
curl --proxy http://proxy.example:8080 --noproxy '' --no-buffer --max-time 30 https://example.com/streamЗа сравнение чрез публично прокси изберете HTTP крайна точка от списъка с HTTP прокси. Използвайте действителния си URL на потока и изберете желаното ограничение. Празният списък за обход запазва това сравнение по избрания маршрут през проксито.
Пристигане, декодиране и показване
Сървърът може да генерира постепенни байтове, посредникът може да ги събира, клиентска библиотека може да прочете цялото тяло, а браузърът може да отложи изобразяването. Сравнявайте първите полезни байтове и последващия напредък там, където контролирате пътя. Времето за рисуване и общата продължителност на сървъра не определят кога пристига тялото.
В Guzzle проверявайте поточното предаване и потреблението на тялото отделно. Компресията добавя етап на декодиране. Промяната в момента, в който се появява декодираният изход, сама по себе си не доказва, че проксито е компонентът за буфериране.
Какво вижда посредникът
Непрозрачно CONNECT прокси не може да анализира вътрешните HTTPS отговори като обикновен HTTP. Оторизирана услуга за TLS инспекция има различна видимост, така че само HTTPS не доказва липсата на инспекция.
След като етапът на изчакване бъде установен, използвайте поддържаните от този компонент контроли за поточно предаване. Директивите на обратното прокси не се прилагат автоматично към предно прокси; флагът за изход на curl променя само неговата част от пътя.