Таймаут только на одном сайте, остальные летают

Странная штука. В прогоне девять площадок, восемь идут ровно, отклик от 300 до 700 миллисекунд. Девятая висит и отваливается по таймауту почти всегда, доходит дай бог одно обращение из двадцати.

Из браузера на той же машине сайт открывается мгновенно. Через curl с той же машины висит. Пробовал поднимать таймаут до трёхсот секунд, всё равно висит, то есть это не медленно, это насмерть.

Куда копать, если восемь соседей по прогону чувствуют себя прекрасно?

Висит на каком месте? Соединение вообще устанавливается или обрывается раньше?

Сейчас посмотрел разбивку, вот она:

dns:       0.031
connect:   0.048
appconnect: 0.000
starttransfer: 0.000
total:     60.001

Соединение встало за 48 миллисекунд, дальше ноль.

Вот это и есть ответ на половину вопроса. connect прошёл, appconnect нулевой, значит висит рукопожатие шифрования. TCP до сайта доходит, а первый большой пакет от него до вас нет.

Такое почти всегда упирается в размер пакета по дороге. Механика простая: рукопожатие начинается с крошечных пакетов, они пролезают везде, а вот ответ сервера с цепочкой сертификата весит килобайта три и режется на куски по размеру канала. Если где-то на пути размер меньше вашего, узел должен прислать назад сообщение «нужна нарезка». Когда это сообщение кто-то по дороге глушит, ваша сторона просто ждёт пакета, который никогда не придёт. Отсюда и красивый ноль в appconnect при живом соединении.

Проверяется за минуту, обычным пингом с запретом на нарезку:

У восьми других площадок цепочка сертификата короче, она влезает в один пакет, поэтому вы про это и не знали.

а браузер тогда почему открывает

Браузер сам щупает размер и снижает его при повторе, у него это встроено. curl честно ждёт, пока ему ответят.

Тимур, до кучи проверьте имена. Бывает похожая картина, когда у сайта есть адрес шестой версии, ваша машина его берёт первым, маршрута туда нет, и вы висите до отката. Симптом такой же: браузер бодрый, консольные утилиты стоят.

Проверить в лоб: curl -4 https://target.example. Если с ключом полетело, ищите в именах.

Проверил, с четвёркой висит ровно так же. И dig AAAA пустой. Значит имена в порядке, остаётся размер пакета.

Тогда правьте на своей стороне, ждать погоды на чужой смысла нет.

Два рабочих хода. Первый: подрезать размер на интерфейсе, через который уходит трафик, ip link set dev tun0 mtu 1400. Второй, более точный: подпилить объявляемый размер сегмента в момент установки соединения, тогда сайт сам пришлёт куски поменьше.

sudo iptables -t mangle -A FORWARD -p tcp --syn -j TCPMSS --clamp-mss-to-pmtu

Клампинг лучше тем, что подгоняет число под реальный путь, руками ничего подбирать не надо.

Добавлю сбоку. Такие висяки удобно ловить сравнением с двух разных точек выхода: если с одной точки сайт висит, а с другой отдаёт за полсекунды, вы сразу знаете, что дело в дороге. Я под это держу отдельный пакет, беру приватные серверные адреса под парсинг и гоняю один и тот же запрос параллельно, с машины и через выход. Пять минут работы, зато версия либо подтверждается, либо отпадает.

поняла, спасибо обоим

Разбор закончен, отписываюсь.

Клампинг сегмента поставил, размер на туннеле опустил до 1400. Девятая площадка пошла с первого обращения, отклик 420 миллисекунд, ровно как у соседей. Параллельно, по совету ostrov, прогнал тот же запрос через вторую точку выхода: там сайт отдавал сразу и без правок, значит резало именно на моём пути.

Что помогло в порядке действий: разбивка по этапам через -w, ноль в appconnect, пинг с запретом нарезки, клампинг. Вся история заняла минут сорок, из них тридцать я потратил на веру в то, что сайт просто медленный. Смотрите на этапы сразу, они экономят вечер.