[Обновить] Я нашел следующие явно связанные записи в HTTPERR журнал:
2018-07-25 14:39:06 ::1%0 49618 ::1%0 701 HTTP/1.1 GET / 400 - Hostname -
2018-07-25 14:39:06 ::1%0 49617 ::1%0 701 HTTP/1.1 GET /favicon.ico 400 - Hostname -
[Оригинал]
Я пытаюсь развернуть .NET Core 2.1 приложение на сервер IIS впервые (я разработчик, а не системный администратор). Поддержка .NET Core была установлена системным администратором, и, поскольку я могу запустить команду из командной строки (см. Ниже), я считаю, что это было сделано правильно.
У нас еще нет сертификата для этого приложения, поэтому я пытаюсь выполнить развертывание с использованием обычного HTTP-доступа (пока все страницы в приложении являются фиктивными данными, и мы занесли в белый список доступ к серверу IIS). Я внес необходимые изменения в код запуска приложений, чтобы избежать перенаправления HTTPS, и считаю, что сделал это правильно (см. Ниже).
Кроме того, это приложение привязано к порту 701 (поскольку 80 уже используется). Полная привязка использует http, имя хоста myapplication.mycompany.com, порт 701, и IP-адрес *.
Приложение развернуто правильно и выглядит "запускаемым" и "останавливаемым" через диспетчер IIS. Однако, когда я просматриваю приложение, через несколько секунд окно браузера закрывается с ERR_CONNECTION_TIMED_OUT сообщение.
Когда я запускаю приложение напрямую, используя dotnet .\myapplication.dll он сообщает о прослушивании 5000, и я могу получить к нему доступ из браузера, запущенного на том же компьютере.
Кроме того, отмечу, что этому приложению в IIS назначен ID 4, но если посмотреть в \inetpub\logs\LogFiles папка Я вижу только папки W3SVC1, W3SVC2 и W3SVC3 и не вижу папки журнала для ID 4.
Наконец, я убедился (я думаю), что AppPool для этого приложения имеет права на выполнение и запись в папке развертывания для приложения.
Может ли кто-нибудь предложить, какой шаг я, возможно, пропустил, чтобы заставить IIS запустить мою обычную службу http или, если это не удается, как я могу отладить проблему без журналов?
В пуле приложений измените версию .NET Framework на «Без управляемого кода».
Отвечая на свой вопрос:
Внешний провайдер, обслуживающий наши частные облачные серверы, правильно добавил запись DNS для myapplication субдомен, но не позаботился о добавлении правила брандмауэра, разрешающего трафик в частное облако на порт 701. Добавление этого правила, по-видимому, устранило проблему.