Анализ заголовков запросов и HTTP-методов: где клоакинг ломается первым

Анализ заголовков запросов и HTTP-методов: где клоакинг ломается первым

Первый слой фильтрации — не IP и не ASN, а сам запрос. Анализ логов показывает: при проверке чаще всего смотрят метод, путь, заголовки и их согласованность между собой. Если GET ведёт себя как POST, а referer пустой там, где он должен быть, цепочка прохождения запроса уже выглядит как подмена.

Разберем техническую составляющую реализации. Для нормального трафика важны три вещи: User-Agent должен совпадать с Accept-Language и типом клиента; Host — с доменом и SNI; method — с логикой страницы. Например, браузерный переход почти всегда даёт GET, а формы, API и вебхуки — ожидаемый POST/PUT. Несостыковка между заголовками и методом — это не «мелочь», а триггер для эвристики.

Отдельно проверяются заголовки-спутники: Referer, Sec-Fetch-Site, Sec-Fetch-Mode, Accept, Cache-Control, Content-Type. Если они отсутствуют, но должны быть, или приходят в порядке, нетипичном для браузера, backend-логика делает простой вывод: запрос собран не клиентом, а прокси-скриптом. Особенно плохо, когда метод меняется по пути через редиректы, а тело запроса не соответствует Content-Length.

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