Правило MSS работает на маршрутизаторе, но не достаёт Squid

Администратор добавляет ограничение TCPMSS в FORWARD. Напрямую маршрутизируемый трафик улучшается, но загрузки через локальный экземпляр Squid всё равно зависают. Соединение прокси с сайтом — это не просто TCP-соединение клиента, проходящее через эту цепочку.

В обычном терминирующем forward-прокси соединение со стороны клиента завершается локально. Прокси создаёт второе TCP-соединение к источнику или родителю. В Linux пакеты, порождённые для этого соединения, идут по локальному пути вывода.

Поэтому правило только для FORWARD может быть совершенно рабочим и всё же промахиваться мимо рукопожатия, которое оно должно было подправить. Прежде чем выбирать точку перехвата, нарисуйте реальное соединение и направление SYN. Контейнеры или отдельные пространства имён могут добавить ещё один маршрутизируемый участок, так что правильное место зависит от того, где работает процесс.

Не вставляйте число PMTU прямо в MSS

MTU пути — это размер IP-пакета. TCP MSS описывает полезную нагрузку TCP и обязан учитывать соответствующие заголовки. Точно так же длина полезной нагрузки ping — не полная длина IP-пакета. Привычная прибавка в 28 байт связана с базовой схемой IPv4 ICMP echo, а не с любым семейством адресов или инкапсуляцией.

Цель TCPMSS документирует явные значения и ограничение PMTU. Ограничение по-прежнему опирается на сведения MTU маршрута; это не доказательство здоровья обнаружения пути и не замена разрешению нужных ICMP-сообщений.

Соотнесите и симптом с теорией. Завершённое рукопожатие с последующими остановками на крупных передачах может оправдать проверку размера пакета. Повторяющиеся SYN без ответа или мгновенный reset требуют более широкого объяснения; сбой мелких пакетов не доказывает слишком большой сегмент данных.

Держите в записи отдельно работающее прямое соединение и сбойное соединение через прокси. Они могут использовать разные источники, маршруты и инкапсуляцию, даже с одной машины.