Ошибка 501: метод не реализован

Ошибка 501 Not Implemented означает, что сервер не умеет выполнить запрос: не знает метод запроса или способ, которым передаются данные. Ситуация довольно редкая: браузер при обычном открытии страниц её почти не может вызвать. Чаще 501 получают программы, интеграции по API и формы, которые отправляют данные на сервер без обработчика. Мы подняли стенд с nginx, Apache, Node и Python, отправили разные методы и заголовки, а затем повторили незнакомый метод на 2056 живых сайтах.

Код ответа своей страницы можно посмотреть нашим сервисом проверки доступности: он запрашивает адрес со своего сервера и показывает, что ответил сайт.

Что значит код ошибки 501

Каждый запрос HTTP содержит метод — глагол, который говорит серверу, что сделать: GET — отдать страницу, POST — принять данные, PUT — сохранить, DELETE — удалить. Стандарт HTTP, RFC 9110, раздел 15.6.2, описывает 501 так: сервер «does not support the functionality required to fulfill the request» — не поддерживает функцию, нужную для выполнения запроса. Это правильный ответ, когда сервер не знает метод и не поддерживает его ни для одного адреса.

Стандарт разводит 501 и 405. В разделе 9.1 сказано: если метод нераспознан или не реализован, сервер должен ответить 501; если метод известен и реализован, но запрещён для этого адреса — 405.

Отличие 501 от 405

Коротко: 405 — «я знаю этот метод, но здесь его нельзя», 501 — «я не умею такой метод вообще». Отличие важно для того, кто пишет интеграцию. При 405 метод можно попробовать на другом адресе того же сервера, при 501 нужен другой сервер или другой способ запроса. На практике многие серверы этих правил не держатся, и стенд ниже это показывает.

Есть и второй случай. Стандарт HTTP/1.1, RFC 9112, требует отвечать 501, если в запросе указан способ передачи тела — заголовок Transfer-Encoding, — которого сервер не понимает.

Стенд: кто отвечает 501, а кто 405

Мы отправили запросы с разными методами к главной странице на четырёх серверах без своих настроек: nginx 1.22 со статикой, Apache 2.4.68 со статикой и со скриптом PHP 8.3, встроенный сервер Node 20 и встроенный сервер Python.

Что из этого следует.

nginx почти не отвечает 501 на метод. На статическую страницу любой метод, кроме GET и HEAD, получил 405 — даже выдуманный FOO. 501 nginx вернул только на незнакомый способ передачи тела: «Transfer-Encoding: foo» и «gzip, chunked». В журнале ошибок nginx при этом строка «client sent unknown "Transfer-Encoding"».

Apache отвечает 501 на незнакомый метод. FOO и «get» строчными буквами получили 501 со страницей «FOO not supported for current URL» и заголовком Allow со списком методов: GET, POST, OPTIONS, HEAD. В журнале — «Invalid method in request FOO / HTTP/1.1».

PHP принимает любой метод. Тот же Apache со скриптом PHP ответил 200 на все методы, включая выдуманный FOO и PROPFIND; отказал он только на TRACE — 405. Что делать с методом, решает уже сам скрипт.

Python отвечает 501 на всё, кроме чтения. Встроенный сервер Python не умеет принимать данные: POST, PUT и любой другой метод получили 501 «Unsupported method».

Прокси пропускает 501 от сервера за собой. Мы поставили nginx перед сервером Python, и посетитель получил 501 от Python. Свои ответы nginx дал только там, где сам отклонил запрос раньше.

Форма, которая получает 501

Мы сделали страницу с формой, которая отправляет данные методом POST, и отправили её из Chromium 149 на три сервера.

Запросы fetch из скрипта страницы с методами PUT, PROPFIND и FOO получили на Python 501, на nginx 405, на Apache — 405, 405 и 501.

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

Наш замер: незнакомый метод на живых сайтах

18.10.2026 мы отправили на главные страницы 2056 сайтов организаций Екатеринбурга по два запроса: обычный GET и запрос с выдуманным методом FOO. Метод FOO ничего не меняет на сайте. На GET ответили 1664 сайта.

Как это читать:

• 501 отвечают в основном сайты за nginx — 262 из 270. Сам nginx на статику отвечает 405, значит, 501 давал сервер за ним, чаще всего Apache.

• 200 на выдуманный метод — 472 сайта. У многих из них в ответе заголовок X-Powered-By с PHP: 41 сайт — PHP 7.2, 26 — PHP 7.4, 11 — PHP 5.6. Как на стенде, скрипт PHP принял любой метод.

• DDoS-Guard отвечает 400 — все 293 сайта за этой защитой.

• Заголовок Allow со списком методов, которого требует стандарт для 405 и который полезен при 501, прислали только 41 сайт из 270.

Наш nexforce.ru работает на nginx: на FOO он ответил 405, а на POST с «Transfer-Encoding: foo» — 501, как стенд.

Вывод: примерно 28 % ответивших сайтов приняли выдуманный метод как обычный, однако один и тот же запрос получает на разных сайтах 200, 400, 405 или 501. Если интеграция работает с одним сервером и падает с 501 на другом, дело в том, что второй сервер этот метод не поддерживает.

Чем 501 грозит владельцу сайта

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

• Формы и заявки. Посетитель нажал «Отправить», получил страницу ошибки, а заявка пропала. Часть потенциальных клиентов уходит, так и не связавшись с компанией. Владелец об этом не узнает, если не следит за журналами или целями в метрике.
• Интеграции. CRM, оплата, доставка и другие сервисы обмениваются с сайтом данными по API. Если сервер не принимает нужный метод, обмен останавливается, а заказы и статусы перестают приходить.
• Сигнал о настройке. Много ответов 501 на запросы, которые сайт должен принимать, — довольно надёжный сигнал, что после переезда или обновления потерялся обработчик.

Инструменты проверки

Диагностика начинается с того, чтобы распознать, кто именно отвечает 501. В большинстве случаев достаточно нескольких инструментов:

• curl — позволяет отправить любой метод и заголовок и увидеть ответ целиком, вместе с Server и Allow.
• Инструменты разработчика в браузере — вкладка «Сеть» показывает метод, код ответа и заголовки каждого запроса, в том числе от форм и скриптов страницы.
• Журналы веб-сервера — их нужно анализировать в первую очередь: в них видно, какой клиент прислал некорректные или неверные запросы и как часто это случается.
• Мониторинг — внешняя проверка, которая регулярно отправляет нужные запросы и может уведомить, если код ответа изменился.

Если сайт работает через провайдера защиты или CDN, проверьте ответ и напрямую с сервера, и через него: промежуточная система иногда использует свои правила и отвечает за сервер по-своему — как DDoS-Guard в нашем замере, который на незнакомый метод отвечал 400.

Почему возникает 501 и что за ним стоит

Причин появления 501 немного. Самые распространённые:

• Сервер не поддерживает метод. Простые и встроенные серверы умеют только отдавать файлы. Методы, которые меняют данные, им незнакомы.
• Нет нужных модулей. Некоторые методы требуют модулей со специфическими функциями: если модуль не установлен или выключен, сервер метод не знает. Например, WebDAV с методами PROPFIND и MKCOL в Apache работает, только если модуль подключён.
• Неправильная настройка прокси. Прокси или балансировщик не пропускает метод дальше или передаёт его не тому серверу.
• Незнакомый Transfer-Encoding. Клиент передаёт тело способом, которого сервер не знает. Так бывает с самописными клиентами и старыми библиотеками.
• Ошибка в коде клиента. Опечатка в названии метода, метод строчными буквами, метод не из той версии API.
• Расширения протокола. Модули и программы, которые расширяют HTTP своими методами, например WebDAV для работы с файлами, работают только с сервером, который эти методы знает. С другим сервером такой клиент получит 501 или 405.

Что делать простому пользователю

Если вы столкнулись с ошибкой 501 и видите её в браузере, исправить ошибку на своей стороне почти нельзя. Но несколько шагов, которые не требуют технических знаний, помогают понять, касается ли проблема только вас:

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

Если вы пользуетесь приложением или сервисом, которое обращается к сайту само, ошибку может вызывать именно оно — например, устаревшая версия. Обновите приложение и попробуйте ещё раз.

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

Шаги для администраторов и владельцев сайтов

Проверить метод HTTP

Чтобы устранить ошибку, действовать нужно по порядку. Сначала выясните, какой метод и с какими заголовками отправляет клиент. В curl метод задаётся флагом -X, а -v покажет запрос и ответ:

curl -v -X PUT https://example.ru/api/zapis/

Ответ 501 с заголовком Allow сразу покажет, какие методы сервер принимает.

Посмотреть журналы

• nginx пишет причину в журнал ошибок: «client sent unknown "Transfer-Encoding"» — незнакомый способ передачи тела.
• Apache пишет «Invalid method in request» с названием метода.
• Если речь идёт о прокси и 501 пришёл с него, а в его журнале ошибок пусто, ищите ответ в журнале сервера за ним.

Обновить конфигурацию сервера

Если метод необходим, его должен обработать кто-то за веб-сервером: скрипт, приложение, модуль. Настройки лежат в конфигурационных файлах сервера; после правки файла их проверяют и сервер нужно перезагрузить или заставить перечитать настройки — у nginx это nginx -t и nginx -s reload. Статический nginx сам данные не принимает — нужен proxy_pass или fastcgi_pass на приложение. В Apache нужный модуль подключают в конфигурации, а методы для адреса ограничивают директивой Require method или блоком Limit.

Обновить серверное программное обеспечение

Устаревшая версия ПО — тоже возможная причина: старые версии серверов и библиотек хуже понимают новые методы и способы передачи. Если 501 появился на методе, который описан в стандарте, проверьте версию сервера и обновите его.

Проверить настройки маршрутизации и DNS

Если ошибка появилась после переезда, убедитесь, что адрес API указывает на новый сервер. Если запросы уходят на старый сервер, где нет обработчика, он ответит 405 или 501 — смотря какое там ПО.

Тестировать вызовы API

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

Как избежать повторения проблемы

• Отвечайте 405 с заголовком Allow, если метод известен, но для адреса запрещён, и 501 — только если сервер не умеет его вовсе. Это помогает разработчикам интеграций быстро понять причину.
• Следите за журналами и за состоянием сервера: всплеск 501 с определённым методом означает, что какой-то клиент отправляет запросы, которые сервер не обрабатывает.
• Проверяйте формы и API после каждого переезда и обновления: именно там чаще всего теряется обработчик.

Похожие ошибки

• Ошибка 405 — метод известен, но для этого адреса запрещён; так nginx отвечает на форму, отправленную на статику.
• Ошибка 505 — сервер не принял версию HTTP из строки запроса.
• Ошибка 451 — доступ закрыт по требованию закона или суда.
• Ошибка 400 — сервер не смог разобрать запрос.
• Ошибка 502 — прокси не получил правильного ответа от сервера за ним.

Границы замера

Стенд — четыре сервера без своих настроек, без WebDAV и без облачных балансировщиков. Microsoft IIS и LiteSpeed мы не проверяли. В обходе отправляли только метод FOO к главной странице: методы, которые могут что-то изменить на чужом сайте, — PUT, DELETE — мы не отправляли.

Коротко

В заключение — главное, что стоит держать в голове.

Ошибка 501 — сервер не умеет выполнить запрос: не знает метод или способ передачи тела. nginx отвечает 501 на незнакомый Transfer-Encoding, а на незнакомый метод — 405; Apache на незнакомый метод отвечает 501, PHP принимает любой. Исправлять нужно клиента, который шлёт неподдерживаемый запрос, или сервер, которому не хватает обработчика.