A regra MSS funciona no router, mas não alcança o Squid

Um administrador adiciona o clamping TCPMSS ao FORWARD. O tráfego encaminhado diretamente melhora, mas os downloads pela instância local do Squid continuam travando. A conexão do proxy com o site não é simplesmente a conexão TCP do cliente passando por essa cadeia.

Num proxy direto terminante comum, a conexão do lado do cliente termina localmente. O proxy cria uma segunda conexão TCP para a origem ou o pai. No Linux, os pacotes gerados para essa conexão seguem o caminho de saída local.

Uma regra só para FORWARD pode, portanto, ser perfeitamente funcional e ainda assim perder o handshake que deveria ajustar. Mapeie a conexão real e a direção do SYN antes de escolher o ponto de gancho. Contêineres ou namespaces separados podem acrescentar outro segmento roteado, então a posição correta depende de onde o processo executa.

Não coloque o número PMTU diretamente no MSS

A MTU do caminho é um tamanho de pacote IP. O MSS do TCP descreve a carga útil TCP e deve considerar os cabeçalhos relevantes. Da mesma forma, o comprimento da carga de um ping não é o comprimento completo do pacote IP. A conhecida adição de 28 bytes está ligada a um arranjo básico de IPv4 ICMP echo, não a todas as famílias de endereços nem a todos os encapsulamentos.

O alvo TCPMSS documenta valores explícitos e o clamping de PMTU. O clamping ainda depende das informações de MTU da rota; não é prova de que a descoberta de caminho esteja saudável, nem substitui permitir as mensagens ICMP necessárias.

Combine também o sintoma com a teoria. Um handshake concluído seguido de travamentos em transferências maiores pode justificar investigar o tamanho do pacote. SYN repetidos sem resposta ou um reset imediato exigem uma explicação mais ampla; a falha de pacotes pequenos não prova um segmento de dados grande demais.

Mantenha separados no registro uma conexão direta que funciona e uma conexão de proxy que falha. Elas podem usar fontes, rotas e encapsulamentos diferentes, até na mesma máquina.