Базовая авторизация и доступ по IP в Nginx: инструкция

За 15–30 минут вы закроете выбранный URL в Nginx сразу двумя проверками: посетитель должен ввести логин и пароль, а его IP — попасть в разрешённый список. Это подходит, например, для тестового сайта или внутренней панели. Покажем настройку для Nginx Open Source 1.24 и новее; перед изменениями проверьте версию и сохраните копию конфигурации.

Что подготовить

Понадобятся доступ к серверу по SSH, права читать и менять конфигурацию Nginx, домен или URL закрываемого раздела и публичный IP, с которого вы будете проверять доступ. Если у вас динамический IP, он может измениться — тогда придётся обновить правило.

Установите утилиту htpasswd для создания файла пользователей. В Debian и Ubuntu она обычно входит в пакет apache2-utils, в системах на базе RHEL — в httpd-tools. Названия пакетов и команда установки зависят от дистрибутива; используйте его официальный менеджер пакетов.

Уточните версию Nginx командой nginx -v. Директивы ниже есть в документации Nginx для актуальных версий Open Source. Конфигурацию перед перезагрузкой проверяйте командой nginx -t.

Настройка по шагам

1. Создайте файл с учётной записью. Укажите путь вне каталога сайта, например /etc/nginx/.htpasswd. Для первого пользователя выполните sudo htpasswd -c /etc/nginx/.htpasswd operator, заменив operator на нужный логин. Утилита запросит пароль интерактивно — не вставляйте его в команду, чтобы он не остался в истории оболочки. Для следующих пользователей повторите команду без ключа -c, иначе вы перезапишете файл. Проверка: файл существует, а команда sudo cat /etc/nginx/.htpasswd показывает логин и строку хеша, но не открытый пароль.
2. Ограничьте права на файл. Убедитесь, что файл не лежит в публичном каталоге сайта и его может читать пользователь, от имени которого Nginx обрабатывает запросы. Не назначайте права на чтение всем пользователям системы без необходимости. Проверка: тест конфигурации и запрос к сайту не дают ошибки чтения файла; если появляется ошибка в журнале, проверьте права и владельца.
3. Добавьте правила в нужный блок server. В примере закрыт путь /admin/. Замените тестовый IP на свой адрес или подсеть в CIDR-формате. Адрес 203.0.113.10 зарезервирован для примеров и не является вашим реальным IP.

server {
    listen 443 ssl;
    server_name example.com;

    location /admin/ {
        auth_basic "Restricted area";
        auth_basic_user_file /etc/nginx/.htpasswd;

        allow 203.0.113.10;
        deny all;

        # Здесь остаются ваши действующие настройки сайта.
    }
}

Этот фрагмент показывает только правила доступа: сохраните существующие настройки TLS, корня сайта и обработки запросов. Если блок location уже есть, добавьте директивы в него, а не создавайте второй блок с тем же путём. Проверка: файл конфигурации содержит правила именно для нужного URL и не публикует файл паролей.

1. Проверьте и примените конфигурацию. Выполните sudo nginx -t. Если проверка завершилась успешно, перечитайте конфигурацию командой sudo nginx -s reload либо используйте принятый в системе способ перезагрузки службы. Проверка: Nginx сообщает об успешной проверке и продолжает обслуживать сайт.
2. Проверьте обе границы доступа. С разрешённого IP откройте закрытый URL: браузер должен запросить учётные данные, а после правильного ввода показать страницу. С другого IP запрос должен получить отказ. Проверка: без пароля закрытая страница не открывается, неверный IP не проходит даже с правильным паролем.

Проверяйте защиту не только «снаружи»: важно убедиться, что запрос действительно приходит в Nginx с ожидаемым IP, а не с адресом балансировщика или прокси.

Если не получилось

• nginx: [emerg] ... could not be loaded или ошибка рядом с auth_basic_user_file. Проверьте точный путь к файлу, права на сам файл и доступ к каталогам по пути. Пользователь Nginx должен иметь возможность прочитать файл.
• nginx: [emerg] unknown directive. Проверьте написание директивы и версию сервера. Запустите nginx -t, чтобы увидеть файл и строку ошибки; не перезагружайте конфигурацию, пока тест не проходит.
• С правильным паролем приходит отказ. Проверьте IP клиента, маску подсети и то, что запрос попадает в ожидающий блок location. За прокси Nginx может видеть адрес самого прокси, а не посетителя.
• Запрос проходит без пароля. Убедитесь, что директивы стоят в нужном location, а не только в другом виртуальном сервере. Проверьте URL с завершающим слешем и без него: для Nginx это могут быть разные варианты обработки.
• После правки сайт перестал открываться. Если nginx -t не проходит, верните резервную копию конфигурации. Если тест проходит, но доступ всё равно нарушен, проверьте журналы ошибок Nginx и убедитесь, что применили конфигурацию именно того экземпляра, который принимает запросы.

Где чаще всего ломается защита

Прокси и балансировщик перед Nginx

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

Правила для всего сайта и отдельного URL

Директивы доступа можно наследовать из родительских блоков, но сочетание настроек в разных уровнях конфигурации легко проверить неверно. Начните с одного явно заданного блока location, протестируйте нужный и соседний URL, затем расширяйте правило. Не добавляйте satisfy any ради того, чтобы «починить» доступ: эта настройка меняет логику сочетания проверок, и одна из них может оказаться достаточной вместо обеих.

Термин. CIDR — запись IP-сети с длиной префикса: например, 192.0.2.0/24 обозначает диапазон адресов, а не один компьютер. Чем меньше диапазон, тем уже список разрешённых адресов.

Что делать дальше

Проверьте доступ с разрешённой и запрещённой сети, включая URL со слешем и без него. Убедитесь, что сайт работает по HTTPS: базовая авторизация не шифрует пароль сама по себе, а передаёт его в запросе, поэтому без TLS учётные данные можно перехватить. Затем добавьте проверку nginx -t в процесс выкладки и заведите порядок смены паролей и обновления списка IP.

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