Como a documentação do Squid diz, a diretiva de configuração reply_body_max_size faz com que o Squid pare a transmissão quando o HTTP O corpo da resposta excede o tamanho especificado. Isso é verificado pelo Squid de duas maneiras: usando o cabeçalho HTTP Content-Length:, se presente - neste caso, a resposta não será permitida e um TCP_DENIED_REPLY será gravado no log. Ou, se um cabeçalho HTTP Content-Length: não estiver presente, a resposta será permitida, mas a conexão será fechada quando reply_body_max_size for atingido.
No segundo cenário, pode haver um efeito potencial potencialmente importante para qualquer cache downstream de você. Se a transmissão HTTP foi iniciada sem um cabeçalho HTTP Content-length: e sua cópia do Squid posteriormente descartou a conexão quando o limite de tamanho da resposta foi atingido, o cache downstream não saberá que a conexão foi descartada antes que o corpo da resposta completa fosse enviei. Isso pode resultar em uma cópia incompleta do objeto sendo armazenado no cache downstream. No entanto, com base na sua descrição, eu não acho que é o caso aqui, como você está falando sobre um proxy upstream operado pelo seu ISP.
Nessa nota, não é possível ver onde um proxy upstream poderia afetar sua capacidade de impor um limite ao tamanho do corpo da resposta.
Uma nota sobre a sintaxe na sua configuração. Você especificou:
reply_body_max_size 10 MB
Quando penso que isto deveria ser realmente:
reply_body_max_size 10 MB all
Anote o nome da ACL "all" no final. A documentação do Squid coloca a lista de ACLs entre colchetes, o que tende a indicar que este parâmetro é opcional, e no meu teste, eu certamente descobri que esse é o caso. No entanto, há uma variação desta sintaxe em alguns lugares na rede (e neste segmento acima), onde às vezes a palavra "permitir" ou "negar" também é colocada na linha de configuração. De acordo com a documentação do Squid, e meu teste, isso está incorreto. A sintaxe acima foi testada corretamente para mim.
Nb. teste realizado com o Squid 3.1.23 e o Squid 3.5.0.2.