Как отключить XML-RPC pingback в WordPress без лишних точек доступа и ошибок в логах

Если на сайте уже отключён XML-RPC целиком, отдельная статья про pingback может показаться лишней. Но на практике бывает другой сценарий: XML-RPC нужен для конкретной интеграции, а pingback и trackback через него — нет. Тогда задача не в полном запрете API, а в точечном закрытии лишнего вектора атак и мусорных запросов.

Это особенно полезно, если в логах регулярно появляются обращения к xmlrpc.php с методами pingback, а в админке или в отчётах безопасности видны попытки перебора. Полностью рубить XML-RPC в такой ситуации не всегда удобно: можно сломать сторонний сервис, мобильный клиент или старую интеграцию. Ниже — рабочие способы, как отключить именно pingback-часть и проверить, что ничего лишнего не осталось.

Когда проблема действительно в pingback

Сначала стоит убедиться, что речь не о другом источнике шума. Pingback и trackback часто путают с обычными комментариями, REST-запросами или ботами, которые просто стучатся в xmlrpc.php. Если закрыть не то, можно получить лишние ошибки и не решить исходную задачу.

Типичные признаки

• в access-логах много POST-запросов к /xmlrpc.php;
• в ответах встречаются методы pingback.ping или похожие XML-RPC вызовы;
• в админке растёт число спамных уведомлений о ссылках;
• сайт не использует обратные уведомления о ссылках, но endpoint остаётся доступным.

Если у вас уже отключён pingback/trackback на уровне настроек WordPress и темы, но endpoint всё равно отвечает, значит, нужен серверный или кодовый слой защиты. Иначе запросы будут доходить до PHP и тратить ресурсы.

Диагностика: что именно отвечает на запросы

Перед изменениями полезно проверить поведение xmlrpc.php вручную. Это несложно и сразу показывает, где узкое место: WordPress, плагин безопасности или веб-сервер.

curl -i https://example.com/xmlrpc.php

Нормально, если файл доступен только как endpoint и не отдаёт содержимое. Но для pingback важнее не сам факт ответа, а то, принимает ли сайт соответствующий метод. Можно отправить тестовый XML-RPC-запрос с методом pingback.ping, но в реальной работе чаще достаточно посмотреть логи веб-сервера и WAF.

Если у вас есть доступ к error log, ищите повторяющиеся записи с xmlrpc.php, pingback.ping и кодами 200/403. Когда запросы проходят до PHP, а не режутся на уровне nginx или Cloudflare, лучше закрыть их раньше.

Способы отключить pingback без полного запрета XML-RPC

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

Вариант 1. Отключить pingback-функциональность через код

Если вам не нужны обратные уведомления о ссылках, можно убрать поддержку pingback на уровне WordPress. Для этого обычно отключают пингбэки и trackback в поддержке комментариев и блокируют сам метод pingback.ping.

<?php
/**
 * Отключает pingback/trackback и метод pingback.ping.
 */
add_filter( 'xmlrpc_methods', function( $methods ) {
    if ( isset( $methods['pingback.ping'] ) ) {
        unset( $methods['pingback.ping'] );
    }

    return $methods;
} );

add_filter( 'pings_open', '__return_false' );
add_filter( 'pre_option_default_pingback_flag', '__return_zero' );
add_filter( 'pre_option_default_ping_status', '__return_zero' );
add_filter( 'pre_option_default_comment_status', function( $value ) {
    return $value;
} );

Этот вариант не отключает весь XML-RPC. Он только убирает pingback-метод и снижает вероятность того, что WordPress будет сам пытаться работать с обратными уведомлениями. Если у вас уже есть mu-plugin для технических правок, это хороший кандидат для него.

Важно: не вставляйте такой код в functions.php активной темы, если тема часто меняется. Для постоянных ограничений безопаснее использовать mu-plugins.

Вариант 2. Закрыть pingback на уровне сервера

Если цель — не только функционально отключить pingback, но и не пускать лишние запросы в PHP, лучше отфильтровать их раньше. На nginx это обычно делается через блокировку xmlrpc.php или через отдельные правила для POST-запросов. Но здесь есть нюанс: если XML-RPC нужен для других методов, полная блокировка файла не подходит.

В такой ситуации серверный слой полезен только тогда, когда вы точно знаете, какие методы должны остаться. На практике это сложнее, чем кодовый вариант, потому что nginx не разбирает XML-RPC-содержимое так же удобно, как PHP. Поэтому чаще сервер используют для общего rate limit или защиты от брутфорса, а не для точечной фильтрации pingback.

Вариант 3. Использовать плагин безопасности

Если у вас уже стоит плагин, который умеет управлять XML-RPC и комментариями, проверьте, нет ли там отдельной опции для pingback или trackback. Это удобнее, чем держать кастомный код, но есть риск включить более жёсткую настройку, чем нужно. Для сайтов, где XML-RPC нужен только частично, это критично.

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

Пошаговое решение без поломки интеграций

Ниже порядок, который обычно даёт предсказуемый результат.

1. Проверьте, используется ли XML-RPC вообще: мобильное приложение, внешняя публикация, старый сервис автопостинга.
2. Если XML-RPC нужен, не отключайте его целиком.
3. Добавьте код, который убирает метод pingback.ping и отключает пинги.
4. Очистите кеш страницы и объектный кеш, если он есть.
5. Проверьте логи и ответ xmlrpc.php после изменения.

Если вы работаете через mu-plugin, структура может быть такой:

<?php
/**
 * Plugin Name: Disable Pingback Only
 */

add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['pingback.ping'] );
    return $methods;
} );

add_filter( 'pings_open', '__return_false' );
add_filter( 'default_ping_status', '__return_zero' );

Файл положите в wp-content/mu-plugins/. Если папки нет, создайте её. Такой подход удобен тем, что код не выключится после смены темы и не потеряется при обновлении обычного плагина.

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

Проверка должна быть не только визуальной. Нужно убедиться, что pingback действительно перестал приниматься, а остальной сайт не пострадал.

• откройте /xmlrpc.php и убедитесь, что сайт отвечает как раньше, если XML-RPC нужен;
• посмотрите access-лог: запросы к pingback.ping должны исчезнуть или получать отказ;
• проверьте, не приходят ли новые уведомления о входящих ссылках;
• если используете внешнюю интеграцию, выполните её тестовый запрос;
• очистите кеш, если ответ мог быть закеширован прокси или CDN.

Для быстрой проверки можно снова посмотреть заголовки ответа:

curl -i https://example.com/xmlrpc.php

Если вы тестируете именно метод, а не сам endpoint, лучше смотреть не только HTTP-код, но и содержимое ответа. При отключённом pingback WordPress должен не принимать соответствующий метод, даже если сам файл доступен.

Частые ошибки и как их исправить

Отключили весь XML-RPC вместо pingback

Это самая частая ошибка. На сайте перестают работать внешние сервисы, а причина оказывается в слишком грубом ограничении. Если XML-RPC нужен хотя бы частично, не блокируйте xmlrpc.php целиком без проверки зависимостей.

Добавили код в тему, а потом потеряли его при обновлении

Для технических ограничений это плохая практика. Если код нужен постоянно, используйте mu-plugin или отдельный мини-плагин. Тогда он не исчезнет после обновления темы.

Проверили только главную страницу, но не лог

Pingback-проблема часто видна не в интерфейсе, а в логах и нагрузке. После внедрения обязательно смотрите access log и, если есть, security log. Иначе можно пропустить повторяющиеся запросы, которые продолжают нагружать сайт.

Не учли кеш и CDN

Если перед сайтом стоит прокси или CDN, старые ответы могут ещё какое-то время жить в кеше. После изменения правил очистите кеш на всех уровнях: WordPress, сервер, CDN.

Безопасность и производительность: что ещё имеет смысл сделать

Если pingback вам не нужен, его отключение — только часть работы. Имеет смысл дополнительно ограничить частоту обращений к xmlrpc.php на уровне WAF или сервера, особенно если сайт регулярно получает брутфорс или мусорные POST-запросы. Это не заменяет кодовую настройку, но снижает нагрузку до того, как запрос попадёт в PHP.

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

И ещё один практический момент: не оставляйте pingback включённым «на всякий случай». Если вы не используете его сознательно, это лишняя поверхность атаки и лишний шум в логах. В рабочем проекте такие вещи лучше закрывать сразу и документировать, где именно это сделано — в mu-plugin, в security-плагине или на уровне сервера.