Nginx http на https не работает удаленно
Я пытался использовать другие ответы на этом сайте, чтобы исправить перенаправление http для установки YouTrack на DO Droplet, но ни один из них не сработал, поэтому я публикую этот вопрос с кратким изложением того, что я нашел. Поскольку это влияет на корневой домен, я сосредоточусь на информации о корневом домене и предположу, что исправление будет применяться к любым поддоменам.
В настоящее время у меня есть доступный конфиг сайтов с двумя включенными файлами.
пример
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name *.example.com;
return 301 https://$host$request_uri;
}
server {
server_name example.com;
listen 443;
#certbot stuff... This works correctly
}
YouTrack
server {
#youtrack certbot https setup. Works correctly.
}
В настоящее время я могу без проблем посещать https://example.com/ и https://projects.example.com/. Тем не менее, когда я пытаюсь посетить http://example.com/ или http://projects.example.com/, я получаю сообщение об ошибке подключения по тайм-ауту.
С помощью curl -I -L http://example.com
на удаленном сервере предоставляет эту информацию:
HTTP/1.1 301 Moved Permanently
Server: nginx/1.10.3 (Ubuntu)
Content-Type: text/html
Connection: keep-alive
Location: https://example.com
HTTP/1.1 200 OK
...
Однако, используя curl -I -L http://example.com
на локальной машине висит ожидание ответа.
1 ответ
Тайм-аут соединения обычно означает неправильную маршрутизацию или брандмауэр. Плохая маршрутизация не вероятна, так как HTTPS-соединение работает, и в общем случае маршрутизация не зависит от содержимого пакета (*).
Может быть, кто-то только открыл HTTPS (порт 443), а не HTTP (порт 80) в брандмауэре, не ожидая, что будет использоваться HTTP.
(*) В Linux вы можете использовать iptables
чтобы пометить пакеты, а затем использовать эти метки межсетевого экрана в расширенных возможностях маршрутизации Linux, чтобы маршрутизировать эти пакеты по-другому, но это было бы исключительным.