Nginx Error: bind() to 0.0.0.0:443 failed (13: Permission denied) Linux / DevOps

Nginx: bind() to 0.0.0.0:443 failed (13: Permission denied) — Решение

Обновлено: 18.08.2026 · Официальная база знаний

При попытке запустить Nginx от имени непривилегированного пользователя (non-root container, non-root user) или при блокировке подсистемой безопасности старт завершается крахом: bind() to 0.0.0.0:443 failed (13: Permission denied) или bind() to 0.0.0.0:80 failed (13: Permission denied).

Причина сбоя	Архитектурный контекст	Механизм блокировки ядра
Привилегированные порты	Порты ниже 1024 (80, 443, 22)	Требуют права суперпользователя (UID 0) или Linux Capabilities
SELinux Policies	RHEL / Rocky / CentOS	Порт 443 не включен в тип `http_port_t`
Безопасные Docker-контейнеры	Запуск под `USER 1001`	Отсутствие `CAP_NET_BIND_SERVICE` у контейнера

Nginx мастер-процесс не может открыть listening-сокет на портах 80/443.
Ошибка часто возникает при развертывании Nginx в защищенных средах Kubernetes (OpenShift, Rootless Docker).

Решение 1 (Предоставление Linux Capability бинарнику Nginx):
Разрешите исполняемому файлу Nginx привязываться к привилегированным портам без полных root-прав:
```
sudo setcap 'cap_net_bind_service=+ep' /usr/sbin/nginx
```
Решение 2 (Изменение диапазона непривилегированных портов ядра Linux):
Разрешите непривилегированным процессам слушать порты начиная с 80 через sysctl:
```
sudo sysctl -w net.ipv4.ip_unprivileged_port_start=80
# Зафиксируйте в /etc/sysctl.d/99-ports.conf для сохранения после ребута
```
Решение 3 (Перенос портов для Rootless контейнеров):
В непривилегированных контейнерах (Nginx Unprivileged) измените порты в конфиге на 8080 и 8443:
```
server {
    listen 8080;
    listen 8443 ssl;
    ...
}
```
Решение 4 (Исправление контекста SELinux):
Если вы используете нестандартный порт SSL (например, 8443), разрешите его в политиках SELinux:
```
sudo semanage port -a -t http_port_t -p tcp 8443
sudo semanage port -m -t http_port_t -p tcp 8443
```
Запустите веб-сервер: sudo systemctl restart nginx.

Архитектурный стандарт: В классической установке на хосте мастер-процесс Nginx ВСЕГДА запускается от пользователя root (он открывает привилегированные порты 80 и 443) и затем немедленно сбрасывает привилегии, порождая рабочие процессы (worker processes) от пользователя www-data / nginx.

Практический опыт инженера: В Red Hat OpenShift запуск контейнеров под root заблокирован через SCC (Security Context Constraints). Настраивайте Ingress-маршрутизацию на порты `8080/8443`.

Частые вопросы (FAQ)

Почему порты ниже 1024 называются привилегированными?

Исторически в UNIX-подобных ОС порты с 1 по 1023 зарезервированы для системных сервисов суперпользователя root, чтобы обычные пользователи не могли перехватить трафик стандартных протоколов (HTTP, HTTPS, SSH, SMTP).

Что делает capability CAP_NET_BIND_SERVICE?

Эта привилегия ядра Linux позволяет процессу привязываться к привилегированным портам (номерам меньше 1024), не требуя предоставления процессу полных прав суперпользователя root.

Как запустить официальный образ nginx от non-root пользователя в Kubernetes?

Используйте специализированный официальный образ nginxinc/nginx-unprivileged, который по умолчанию слушает порт 8080 и работает под UID 101.

Как проверить, какие capabilities установлены на бинарнике Nginx?

Выполните команду getcap /usr/sbin/nginx.