Nexus Repository OSS reverse proxy
Solution 1:
In a reverse proxy setup, Nexus looks for the presence of various X-Forwarded-*
HTTP headers in order to determine its base URL. As long as you set these headers correctly, it should produce the correct URLs, no outbound rules needed.
The trick is to know which ones to pass -- the reverse proxy documentation doesn't seem particularly clear about what those are, they just offer up nginx and Apache samples without much explanation. I suspect nginx and Apache set the necessary headers automatically, and Nexus has adopted those. This is all a "de facto standard" as opposed to a formal one, so while you see a fair amount of consistency in which headers are supported across applications, it's not guaranteed.
These are the two I needed in my case:
-
X-Forwarded-Host
tells Nexus the original host requested by the client. This would be "nexus.mycompany.com" in your example. -
X-Forwarded-Proto
can be used to tell Nexus that the original request (i.e. to your proxy) was HTTPS, even if Nexus itself isn't running HTTPS. If your proxy isn't HTTPS, then you shouldn't need this.
Headers are set in the Server Variables section -- replace dashes with underscores and slap an "HTTP_" on the front, so X-Forwarded-Host
becomes HTTP_X_Forwarded_Host
.
So the rule would end up looking like this:
<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>
Again, take out the Proto one if your reverse proxy isn't HTTPS.
With those headers set, you shouldn't need the outbound rule, which as you noted isn't able to catch a lot of the stuff happening in the Javascript files.
As a final aside, you may want to consider leaving that Base URL capability in there -- according to the docs it does get used for a few things.