Вопрос или проблема
Конфигурация, которую я настроил (ниже), работает для localhost
, но не для моего домена. Цель состоит в том, чтобы получить доступ к порту 3000 извне с базовой аутентификацией, чтобы только я мог его использовать. Когда я перехожу на localhost
, соединение обновляется до https
, я должен пройти аутентификацию, и затем порт 3000 отображается, как и должно быть. Однако, когда я перехожу на api.example.com
, аутентификация не запрашивается, соединение не обновляется, и отображается Invalid Host header
. Когда я открываю порт 3000 для перенаправления и перехожу на api.example.com:3000
, я могу получить доступ к порту, но аутентификация не требуется, https
не используется, и моя цель – избежать перенаправления портов. Эта конфигурация пришла из инструкций, поэтому я не знаю, в чем может быть проблема. Почему мой поддомен не работает с этой конфигурацией?
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
upstream supabase {
server 127.0.0.1:3000;
}
server {
listen 80;
server_name localhost *host IP* api.example.com;
access_log off;
rewrite ^ https://$host$request_uri? permanent;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name localhost *host IP* api.example.com;
ssl_certificate /etc/api.example.com/fullchain.pem;
ssl_certificate_key /etc/api.example.com/privkey.pem;
# STUDIO
location / {
auth_basic "Authentication Required";
auth_basic_user_file /etc/nginx/.htpasswd;
proxy_set_header Host $host;
proxy_pass http://supabase;
proxy_redirect off;
proxy_set_header Upgrade $http_upgrade;
}
}
Брандмауэр:
sudo ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), deny (routed)
New profiles: skip
To Action From
-- ------ ----
80/tcp (Nginx HTTP) ALLOW IN Anywhere
80 ALLOW IN Anywhere
443 ALLOW IN Anywhere
80/tcp ALLOW IN Anywhere
443/tcp ALLOW IN Anywhere
8000 ALLOW IN Anywhere
80,443/tcp (Nginx Full) ALLOW IN Anywhere
443/tcp (Nginx HTTPS) ALLOW IN Anywhere
80/tcp (Nginx HTTP (v6)) ALLOW IN Anywhere (v6)
80 (v6) ALLOW IN Anywhere (v6)
443 (v6) ALLOW IN Anywhere (v6)
80/tcp (v6) ALLOW IN Anywhere (v6)
443/tcp (v6) ALLOW IN Anywhere (v6)
8000 (v6) ALLOW IN Anywhere (v6)
80,443/tcp (Nginx Full (v6)) ALLOW IN Anywhere (v6)
443/tcp (Nginx HTTPS (v6)) ALLOW IN Anywhere (v6)
Ваш серверный блок для порта 80 настроен только на имя localhost
.
server_name localhost;
Домен api.example.com
отсутствует здесь. Поэтому запрос к этому домену через HTTP захватывается серверным блоком по умолчанию из конфигурации nginx по умолчанию.
Добавьте домен здесь, как вы сделали это в SSL серверном блоке.
server_name localhost api.example.com;
Сомневаюсь, что ваше DNS имя действительно api.example.com – но это хорошая практика НЕ публиковать это здесь. Тем не менее, эта ошибка ожидается, если вы предоставите недопустимое имя хоста – то есть содержащее символы, отличные от a-z, 0-9, ‘.’ и ‘-‘. Это может быть непреднамеренно – отсутствие завершающего ‘;’ в списке имен, вероятно, приведет к тому же результату. В таком сценарии nginx откажется загрузить файл конфигурации. Всегда полезно протестировать вашу конфигурацию с помощью nginx -t
перед применением; ‘systemctl reload nginx’ не скажет вам, что у вас плохая конфигурация.
Добавьте эти две строки в ваш /etc/hosts
127.0.0.1 your_domain
127.0.0.1 www.your_domain
Тогда вы сможете получить к ним доступ через http://your_domain или http://www.your_domain
Попробуйте перезапустить nginx с помощью
sudo systemctl reload nginx
Перезапустите ваш браузер, и он теперь загрузится
Ответ или решение
Проблемы с доступом к Nginx по доменному имени и их решения
Если у вас возникли сложности с доступом к вашему приложению, работающему на Nginx и доступному через доменное имя (api.example.com), но при этом все работает на локальном хосте, давайте разберем основные причины и возможные решения этой проблемы.
1. Проверьте конфигурацию Nginx
Ваши конфигурационные файлы Nginx могут содержать ошибки, которые влияют на доступность вашего приложения по указанному домену. В данном случае важно, чтобы указанные вами серверные блоки содержали правильные server_name
.
Предложение по улучшению конфигурации:
В вашем файле конфигурации, блок для HTTP (порт 80) не содержит api.example.com
в server_name
. Это означает, что запросы к вашему доменному имени могут обрабатываться не тем сервером, что и приводит к ошибкам, таким как "Invalid Host header". Измените ваш блок на следующий:
server {
listen 80;
server_name localhost api.example.com; # Добавьте домен здесь
access_log off;
rewrite ^ https://$host$request_uri? permanent;
}
Это позволит Nginx обрабатывать запросы к домену и перенаправлять их на HTTPS автоматически.
2. Проверьте DNS записи
Убедитесь, что ваш домен (api.example.com) правильно настроен и указывает на ваш IP-адрес сервера. Вы можете использовать утилиты, такие как dig
или nslookup
, для проверки:
dig api.example.com
Убедитесь, что в ответ вы видите IP-адрес вашего сервера. Если DNS-записи не настроены верно, ваши запросы не будут достигать сервера, и ошибка "Invalid Host header" будет повторяться.
3. Проверка настроек брандмауэра
Ваш брандмауэр также должен позволять трафик на портах 80 и 443. Судя по предоставленной информации, брандмауэр UFW настроен корректно, однако стоит дважды проверить:
sudo ufw status verbose
Убедитесь, что порты 80 и 443 открыты для внешнего трафика.
4. Настройка hosts
Если вы хотите тестировать доступ на вашем локальном компьютере, добавьте записи в файл /etc/hosts
, как указано в вашем вопросе:
127.0.0.1 api.example.com
Однако это может быть не актуально для удаленного доступа к серверу. Для этого важно, чтобы DNS записи в интернете правильно указывали на ваш сервер.
5. Тестирование конфигурации Nginx
Перед применением изменений настоятельно рекомендуется проверить конфигурацию Nginx:
sudo nginx -t
Это поможет избежать случайных ошибок при перезагрузке сервера. Если тест пройдет успешно, перезагрузите Nginx с помощью:
sudo systemctl reload nginx
Заключение
Обеспечение доступа к вашему приложению по доменному имени требует правильно настроенного веб-сервера, корректных DNS записей и открытых портов. Следуя данным рекомендациям, вы сможете устранить проблемы с доступом к вашему приложению. Убедитесь, что вы провели все проверки и применили необходимые исправления, чтобы получить рабочую конфигурацию Nginx.