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의 출력 플래그는 경로에서 자기 부분만 바꿉니다.