Перенаправление HTTPS иногда не работает в IIS

Информация об окружающей среде:

• Windows Server 2012 R2
• IIS 8
• Модуль 2 перезаписи URL-адресов IIS (13.04.2015) 7.2.2
• Умбрако 7.11.1

Описание конфигурации

У нас есть сайт Umbraco, который привязан к двум основным доменным именам, назовем их sitea.com и siteb.com - на сайтах одинаковый исходный код и развертывание, но совершенно разный контент. В IIS сайты также привязаны к www.sitea.com и www.siteb.com

Кроме того, у нас есть сайты, защищенные LetsEncrypt для всех 4 доменных имен.

Сайт должен быть на HTTPS, и у нас также есть ключ umbraco для useSSL, установленный на true.

<add key="umbracoUseSSL" value="true" />

Переписать конфиг

У нас есть ряд перенаправлений, вся конфигурация перезаписи вставлена ​​ниже в анонимной форме:

    <rewrite>
            <rules>
                <rule name="Allow LetsEncrypt" patternSyntax="Wildcard" stopProcessing="true">
                    <match url=".well-known/*" />
                    <action type="None" />
                </rule>
                <rule name="Remove WWW" patternSyntax="Wildcard" stopProcessing="false">
                    <match url="*" />
                    <conditions>
                        <add input="{CACHE_URL}" pattern="*://www.*" />
                    </conditions>
                    <action type="Redirect" url="{C:1}://{C:2}" redirectType="Permanent" />
                </rule>
                <rule name="HTTPS" patternSyntax="Wildcard" stopProcessing="false">
                    <match url="*" />
                    <conditions>
                        <add input="{HTTPS}" pattern="off" />
                    </conditions>
                    <action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" redirectType="Permanent" />
                </rule>
            </rules>
        </rewrite>

Подводя итог, есть 3 правила

1. Правило обхода, поэтому, когда LetsEncrypt проверяет ~ /. Well-known, он не перехватывается перенаправлениями
2. Перенаправление, при котором при посещении www.sitea.com или www.siteb.com вы будете перенаправлены на {протокол}: //sitea.com в зависимости от того, по какому протоколу вы вошли на сайт.
3. Дополнительное перенаправление, которое определяет, включен ли HTTPS, а если нет, перенаправляет вас на https: // {domain} / {path}

Эта проблема

Иногда, как было отмечено нашим мониторингом и ручной проверкой, если вы посещаете http://sitea.com тогда вы будете перенаправлены на https://sitea.com:80

Обратите внимание на добавление порта 80 в URL-адрес перенаправления. Это приводит к тому, что сайт не загружается, поскольку мы указываем https, но используем привязку http.

Если мы сбросим пул приложений для сайта, проблема сразу же исчезнет. Эта проблема может сохраняться в течение нескольких часов, а затем может исправиться сама собой, однако это может быть вызвано сбросом пула приложений в абсолютное время или по запросу приложения (мы не исследовали это)

Я не вижу ничего неправильного в конфигурации перенаправления, которая могла бы вызывать это, и это проблема, которая возникает только периодически. У нас есть другие веб-сайты на том же сервере в IIS с очень похожими структурами перенаправления и привязки, но они не проявляют тех же симптомов.

Если это актуально, в Umbraco есть два дерева контента, каждое из которых привязано к sitea.com и siteb.com соответственно. Я упоминаю об этом только в том случае, если проблема заключается в приложении, а не в конфигурации перезаписи URL.

Кто-нибудь видел раньше этот баг? Есть простое решение?

Настройка правила перезаписи для включения порта и FRT

Следуя предложению из комментариев по моему вопросу, я включил FRT, используя https://docs.microsoft.com/en-us/iis/extensions/url-rewrite-module/using-failed-request-tracing-to-trace-rewrite-rules

Сначала мне пришлось установить его как модуль IIS, а затем «отремонтировать» модуль перезаписи URL-адресов, чтобы параметры трассировки стали доступны. Я настроил это с ответами 300-301.

Я ждал, когда проблема повторится, а затем, когда это произошло, я проверил журналы.

Я вижу, что есть REDIRECT_FROM_CACHE_ACTION как часть URL-адреса перезаписывать данные с CachedRedirectedUrl значение https://sitea.com:80/ по запросам после возникновения неисправности. Это объясняет, почему проблема начинается, а затем не разрешается автоматически до тех пор, пока не будет сброшен пул приложений, выходные данные перенаправления кэшируются, а сброс не очищает кеш.

Проверка более ранних журналов FRT (чтобы узнать, откуда был кэширован запрос) приводит меня к следующему:

Здесь мы видим, что оценка правила HTTPS начинается, совпадает, но полученный URL-адрес перенаправления после замены токенов в <action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" redirectType="Permanent" /> является https://sitea.com:80 (запись № 28, RedirectURL)

Я изменил правила перезаписи так, чтобы правило HTTPS читалось

<rule name="HTTPS" patternSyntax="Wildcard" stopProcessing="false">
          <match url="*" />
          <conditions>
            <add input="{HTTPS}" pattern="off" />
          </conditions>
          <action type="Redirect" url="https://{HTTP_HOST}:443{REQUEST_URI}" redirectType="Permanent" />
        </rule>

Это не похоже на необходимость, поскольку порт должен выводиться из протокола, если он не указан, но, возможно, это ошибка при перезаписи URL? Через несколько дней возникла исходная проблема, на этот раз с перенаправлением для https://sitea.com:80:443/ (что является недопустимым перенаправлением с двумя портами). **

Изменить 1: я вытащил источник для u7.11.1 и проверил использование umbracoUseSSL, и, похоже, он используется только внутри бэк-офиса, некоторых уведомлений и маршрутов api. Отрисовка передней страницы не проверяет эту переменную и не пытается перенаправить https. Таким образом, это говорит о том, что проблема связана с приложением.

Изменить 2: объединил предложенный мной ответ с исходным вопросом, потому что он не решил проблему (это ухудшило ситуацию)