У меня есть сервер Windows Server 2012-R2, на котором запущен Nexus Repository OSS на localhost:8081. Я настроил обратный прокси в IIS со следующим правилом:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="ReverseProxyInboundRule1" stopProcessing="true">
<match url="(.*)" />
<action type="Rewrite" url="http://localhost:8081/{R:1}" />
</rule>
</rules>
<outboundRules>
<preConditions>
<preCondition name="ResponseIsHtml1">
<add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />
</preCondition>
</preConditions>
</outboundRules>
</rewrite>
</system.webServer>
</configuration>
Когда я захожу на сайт из другой системы и перехожу на nexus.mycompany.com, я вижу, что прокси работает ... в основном. Все зависимые css, js и т. Д. Все localhost:8081 что, конечно, не может решить удаленная машина.
Я попытался добавить правило для исходящего трафика, надеясь, что оно решит проблему, но этого не произошло.
<rule name="ReverseProxyOutboundRule1" preCondition="ResponseIsHtml1">
<match filterByTags="A, Form, Img" pattern="^http(s)?://localhost:8081/(.*)" />
<action type="Rewrite" value="http{R:1}://nexus.mycompany.com/{R:2}" />
</rule>
Глядя на документация, Я попытался установить базовый URL. Описываемая кнопка отсутствует в графическом интерфейсе. Я нашел статью о переполнении стека, в которой объясняется, что она перемещена в раздел «Возможности». Я добавил базовый URL-адрес через возможности, но он все еще не работает.
Я перезапускал службу Windows после каждого изменения.
Я хочу, чтобы репозиторий был доступен через имя хоста и загружался соответствующим образом. Я упустил что-то очевидное? Есть ли другая причина, по которой он использует полные URL-адреса вместо относительных?
При настройке обратного прокси Nexus проверяет наличие различных X-Forwarded-* Заголовки HTTP для определения его базового URL. Если вы правильно настроили эти заголовки, они должны выдавать правильные URL-адреса, правила для исходящего трафика не требуются.
Хитрость в том, чтобы знать, какие из них пройти - документация обратного прокси не кажется особенно ясным, что это такое, они просто предлагают образцы nginx и Apache без особых объяснений. Я подозреваю, что nginx и Apache устанавливают необходимые заголовки автоматически, и Nexus принял их. Все это является «стандартом де-факто» в отличие от формального, поэтому, хотя вы видите изрядную согласованность в том, что заголовки поддерживаются в разных приложениях, это не гарантируется.
Вот те два, которые мне понадобились в моем случае:
X-Forwarded-Host сообщает Nexus исходный хост, запрошенный клиентом. В вашем примере это будет nexus.mycompany.com.X-Forwarded-Proto может использоваться, чтобы сообщить Nexus, что исходный запрос (то есть к вашему прокси) был HTTPS, даже если сам Nexus не использует HTTPS. Если ваш прокси-сервер не HTTPS, он вам не нужен.Заголовки задаются в разделе «Переменные сервера» - замените тире на подчеркивание и вставьте «HTTP_» спереди, чтобы X-Forwarded-Host становится HTTP_X_Forwarded_Host.
Таким образом, правило будет выглядеть так:
<rule name="ReverseProxyInboundRule1" stopProcessing="true">
<match url="(.*)" />
<action type="Rewrite" url="http://localhost:8081/{R:1}" />
<serverVariables>
<set name="HTTP_X_Forwarded_Proto" value="https" />
<set name="HTTP_X_Forwarded_Host" value="nexus.mycompany.com" />
</serverVariables>
</rule>
Опять же, удалите Proto, если ваш обратный прокси не HTTPS.
Когда эти заголовки установлены, вам не нужно правило исходящего трафика, которое, как вы отметили, не может улавливать большую часть того, что происходит в файлах Javascript.
В заключение, вы можете подумать о том, чтобы оставить там эту возможность базового URL - согласно документы он привык к нескольким вещам.