Ошибка 406 Not Acceptable: что значит и как исправить на WordPress

Ошибка 406 Not Acceptable на сайте выглядит пугающе, но причина у неё почти всегда одна и простая: сайт защищает сам себя от того, что принял за атаку, и по ошибке блокирует обычный текст. Разберём по порядку, как это отличить от других поломок и что делать, чтобы ошибка не вернулась.

Инструкция актуальна для любой версии WordPress и для сайтов, которые стоят как за классической защитой хостинга, так и за облачными сервисами вроде Cloudflare — сейчас это вторая по частоте причина после защитного модуля хостинга.

Что означает ошибка 406

Дословно 406 значит «неприемлемо». Формально сервер отвечает: я получил запрос, понял его, но отдавать ответ отказываюсь.

По спецификации HTTP код 406 означает, что браузер запросил формат ответа, которого у сервера нет. На реальных сайтах на WordPress это почти никогда не так — браузеры и админка WordPress запрашивают вполне стандартные форматы. Причина в другом месте: на сервере стоит защитный барьер, и именно он решил, что запрос выглядит подозрительно.

Если вы просто зашли на сайт и видите 406

Сначала короткая проверка. Она займёт минуту и часто помогает сразу.

1. Обновите страницу. Иногда сбой разовый.
2. Удалите куки этого сайта и зайдите снова. Старая запись в браузере может выглядеть для защиты подозрительно.
3. Выключите VPN и расширения: блокировщик рекламы, переводчик, «защитник». Они меняют запрос, и сервер его не пускает.
4. Откройте сайт в другом браузере или с телефона через мобильный интернет.

Если в другом браузере всё работает — дело было в вашем браузере. Если ошибка везде — сломано у владельца сайта. Напишите ему, на какой странице и в какое время это было. Дальше в статье — что делать владельцу.

Причина в девяти случаях из десяти

Её выдаёт защитный модуль на сервере хостинга — чаще всего это ModSecurity, программа-фильтр, которую подключает почти любой хостинг на Apache или LiteSpeed для защиты от атак. Она читает каждый запрос и сверяет его с базой шаблонов вредоносного поведения.

Беда в том, что шаблоны широкие, а не точные. Они ищут признаки SQL-инъекций, вставки чужого кода и попыток взлома форм — и под эти признаки нередко попадает совершенно безобидный текст.

Типичные ситуации, в которых это происходит:

• в тексте статьи или комментарии есть фрагмент кода, SQL-запрос или строка вроде SELECT * FROM;
• в поле формы человек написал слово «select», «union» или использовал кавычки и угловые скобки подряд;
• вы сохраняете страницу с большим объёмом HTML-разметки или длинным JSON внутри блока Gutenberg;
• плагин или тема отправляет запрос с необычно длинным набором параметров в адресной строке.

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

Вторая частая причина: облачная защита сайта

Если сайт подключён к Cloudflare или похожему сервису (это бесплатная и очень распространённая практика — CDN и защита от одного и того же провайдера), запрос сначала проходит через него и только потом попадает на хостинг. Заблокировать его может уже эта облачная защита, ещё до сервера.

Отличить её от ModSecurity хостинга просто по одному признаку: если временно отключить прокси Cloudflare для домена (в настройках DNS перевести запись из «облачной» в «только DNS») и ошибка исчезла — дело было в облачной защите, а не на сервере.

У Cloudflare для этого есть отдельная панель: раздел «Security → Events» показывает точный заблокированный запрос и правило, которое сработало. Через тот же раздел можно снять блокировку для конкретного адреса страницы, не трогая защиту всего сайта.

Таблица: как отличить причину по симптомам

Прежде чем писать в поддержку, стоит понять, где именно застрял запрос — это экономит один круг переписки.

Как убедиться, что дело именно в этом

Уберите из текста подозрительный фрагмент — код, SQL-запрос, необычные символы — и попробуйте сохранить снова. Получилось — причина найдена, и дальше речь только о том, как сохранить этот фрагмент безопасно.

Второй признак: ошибка приходит мгновенно, без задержки. Сайт до полноценной обработки запроса даже не доходит — блокировка срабатывает раньше, чем WordPress успевает что-то сделать.

Третий способ проверки — открыть страницу с тем же действием в режиме инкогнито или на телефоне через мобильный интернет, а не через Wi-Fi офиса. Если ошибка пропала, вероятная причина — правило, привязанное к сети или IP-адресу, а не к содержимому.

Что делать по порядку

1. Определите по таблице выше, где вероятнее всего застрял запрос. Это экономит время: не нужно одновременно писать хостингу и разбираться с Cloudflare.
2. Обратитесь в поддержку хостинга или откройте панель облачной защиты. Опишите точное действие, которое вызывает ошибку, и попросите посмотреть журнал защитного модуля — им видно, какое именно правило сработало.
3. Попросите добавить точечное исключение, а не выключить защиту. Хорошая поддержка добавляет исключение для конкретной формы, поля или адреса страницы — весь остальной сайт остаётся под защитой.
4. Если фрагмент кода нужен в самой статье, вставляйте его через специальный блок для кода в редакторе, а не обычным текстом — тогда он передаётся в кодированном виде и не совпадает с шаблонами атак.
5. Проверьте плагины, если первые три шага не помогли. Отключите их по одному, начиная с тех, что работают с формами и безопасностью, и повторите проблемное действие после каждого отключения.

Что написать в поддержку хостинга

Расплывчатое «у меня ошибка 406, помогите» увеличивает переписку на два-три письма. Поддержка отвечает быстрее и точнее, если сразу получает три вещи.

Если сайт стоит за Cloudflare, добавьте отдельную строку: «Проверил(а) также раздел Security → Events в Cloudflare — блокировки [нашёл(ла) / не нашёл(ла)]». Это сразу показывает поддержке хостинга, что причину уже сузили, и экономит цикл вопросов «а вы проверяли CDN».

Причины, которые встречаются реже

Конфликт плагинов. Плагины безопасности вроде файрвола на уровне WordPress иногда дублируют защиту хостинга и добавляют свои блокировки поверх. Проверяется отключением по одному, начиная с тех, что работают с формами и безопасностью.

Ручное правило в конфигурации сервера. Иногда администратор прописывает код 406 вручную для блокировки нежелательных запросов — например, старых версий ботов — а затем забывает про это правило. Спросить об этом напрямую в поддержке — законный вопрос.

Ошибка в теме или расширении. Редко, но бывает: код темы или плагина сам отдаёт статус 406 там, где должен был отдать другой — например, при неверной проверке заголовка запроса. Проверяется откатом на стандартную тему WordPress.

Поддержка сайта на WordPressРазбираем такие ошибки, следим за обновлениями и защитой — от 25 000 ₽/мес

Как проверить, что ошибка не вернётся

Повторите ровно то действие, которое ломалось, с тем же содержимым. Ошибка, которая «больше не появляется» после одной удачной попытки, часто просто ждёт следующего похожего текста или следующей похожей формы.

Сохраните пример проблемного текста или скриншот формы. Если ошибка вернётся после обновления хостингом защитных правил, вы за минуту подтвердите поддержке, что причина та же, и не будете объяснять всё заново.

Если сайт для вас ведёт кто-то другой — фрилансер или подрядчик, который давно не отвечает — прежде чем разбираться с 406 самостоятельно, стоит проверить, в каком состоянии сайт вообще: как устроена защита сети и сайта простыми словами — разбор для тех, кто не хочет становиться администратором сервера, но должен понимать, что вообще происходит.

Аудит безопасности сайтаПроверим версии CMS, защитные модули, формы и резервные копии — и подскажем, что закрыть первым