Gitlab Behind Reverse Proxy- Files (but not interface) served with wrong hostname

Hi there!

I have a strange reverse proxy issue that cropped up after upgrading to version 13. For some reason, upon upgrading to the latest version of gitlab-ee (I was on 12.10.something before) both my NGINX and HAProxy reverse proxy servers no longer rewrite what I am assuming to be the Location header of individual files within my gitlab code repositories.

To elaborate, I have an external DNS record that gets proxied through a HAProxy server to my gitlab server, which internally is known as

I thought maybe it was my HAProxy configuration, as I just switched to HAProxy from NGINX, however my “known-good” NGINX configuration has the same issue. Whereas, in version 12 of gitlab-ee this problem did not exist.

The Problem:
The interface and nearly all functionality of gitlab works perfectly through the proxy. I can sign in to gitlab using my proxy URL and the headers all look correct in both my requests to the proxy and responses from the poxy, according to cURL

However if I go to look at a specific file, any individual file within a code repository in gitlab, the second I click on an individual file in the repository, the URL is not rewritten by the proxy. So for instance if I was looking at a project and I wanted to look at a file like main.cpp within said project, if I click on that file and I’m outside of my network, the request will fail because the file shows as being served from and not

Can anyone tell me what headers I might need to rewrite on my proxy to resolve this issue? Or if anything changed between 12.10 and 13 involving how git repository files are served?

Thanks y’all!

1 Like

Bump. Having similar issue.

I’ve been combing through the documentation here.

Could this issue have something to do with the referrer-policy header or the trusted_proxies setting? What about proxy-headers?

At the moment my Gitlab instance is served by the builtin NGINX server and I make all connections to it over https. I don’t believe I have set an external_url or the referrer-policy header. I don’t believe I’ve set anything under trusted_proxies either.

Is the external_url relevant to a reverse proxy running on a separate VM? What about the trusted_proxies setting? Do I need to connect via the proxy to the Gitlab instance using http only in order for the proxy server to correctly rewrite links to the repository files?

Does anyone have any experience with this issue? Is anyone using haproxy in front of their Gitlab and willing to share their configuration assuming they do not have this issue? I’m stumped. I’d be willing to provide my configuration for both the gitlab embedded nginx and my external haproxy to see if this is a bug that can be recreated. The proxy serves several other enterprise applications and none of them have this issue. We really need to get this fixed.

Alright. I dug a little deeper. The issue is with a portion of the repository page which appears to have hardcoded (or dynamically generated) full URLs in the response BODY and thus the issue is in the BODY and NOT the headers. Trying to rewrite a response body is like pulling teeth and is apparently extremely expensive in terms of proxy performance.

Looking at the page source, I’m thinking that the gon.gitlab_url is what is generating the links on the repository page. It looks like gon.gitlab_url is set via the external_url variable in the embedded NGINX configuration. I’m going to try to set external_url to the URL used by the reverse proxy and see if this fixes the issue, however this then makes gitlab entirely dependent on the functionality of my reverse proxy, I would think. This works as a band-aid fix for me because I intend to only access the GitLab server through the proxy server, but I’m sure many would agree that this is not the optimal scenario.

If the proxy goes down I will need to reconfigure the external URL if I want to access Gitlab over http(s). I would also think that trying to access the GitLab server directly, not via the proxy but via the GitLab server’s DNS name, would then cause issues as well, because most of the site would be served over but the links generated from the external_url would be pointing to

I think I will submit an issue over on the GitLab code pages and see if there’s anything that can be done about this. To anyone watching this thread, sorry for the constant updates, I really need to get this operational and I thought it would be good documentation to post here in case someone else comes along with the same problem.