Я попытался использовать другие ответы на этом сайте, чтобы исправить перенаправление http для установки YouTrack на капли DO, но ни один из них не работал, поэтому я публикую этот вопрос с кратким описанием того, что я нашел. Поскольку это влияет на корневой домен, я сосредоточусь на информации о корневом домене и предполагаю, что исправление будет применяться к любым поддоменам.
В настоящее время у меня есть доступная для сайтов конфигурация с двумя включенными файлами.
пример
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
на локальной машине зависает в ожидании ответа.
Тайм-аут подключения обычно означает неправильную маршрутизацию или брандмауэр. Плохая маршрутизация маловероятна, поскольку соединение HTTPS действительно работает, а маршрутизация в общем случае не зависит от содержимого пакета (*).
Возможно, кто-то открыл в брандмауэре только HTTPS (порт 443), а не HTTP (порт 80), не ожидая использования HTTP.
(*) В Linux вы можете использовать iptables
чтобы пометить пакеты, а затем использовать эти метки брандмауэра в расширенных возможностях маршрутизации Linux, чтобы маршрутизировать эти пакеты по-другому, но это было бы исключением.