Gitlab Registry: 301 Redirects behind nginx reverse proxy

Having trouble getting the Gitlab (omnibus) registry working that is setup behind an nginx reverse proxy. I end up getting a bunch of 301 redirects.

This is the reverse proxy config:

server {
listen 443 ssl;
server_name gitlabreg.domain.com;
set $requestedhost gitlabreg.domain.com;
ssl on;
include ssl/ssl.conf;
ssl_certificate ssl/labs.crt;
ssl_certificate_key ssl/labs.key;
location / {
modsecurity_rules_file /usr/local/nginx/conf/modsecurity.conf;

            proxy_pass      https://192.168.0.236:4567/$request_uri;
            proxy_set_header        X-Real_IP       $remote_addr;
            proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header        Host            $http_host;
            client_max_body_size 0;
    }

}

And this is what I have in gitlab.rb:

registry_external_url ‘https://gitlab.domain.com:4567

I’ve also tried adding these two lines:
registry_nginx[‘enable’] = true
registry_nginx[‘listen_port’] = 4567

Whatever I try seems to result in a 301 redirect that looks like this in the logs:

192.168.1.1 - - [09/Jan/2019:15:06:48 -0500] “GET //v2/ HTTP/1.0” 301 0 “” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”
192.168.1.1 - - [09/Jan/2019:15:06:48 -0500] “GET //v2/ HTTP/1.0” 301 0 “” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”
192.168.1.1 - - [09/Jan/2019:15:06:48 -0500] “GET //v2/ HTTP/1.0” 301 0 “” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”
192.168.1.1 - - [09/Jan/2019:15:06:48 -0500] “GET //v2/ HTTP/1.0” 301 0 “” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”
192.168.1.1 - - [09/Jan/2019:15:06:48 -0500] “GET //v2/ HTTP/1.0” 301 0 “” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”
192.168.1.1 - - [09/Jan/2019:15:06:48 -0500] “GET //v2/ HTTP/1.0” 301 0 “” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”
192.168.1.1 - - [09/Jan/2019:15:06:48 -0500] “GET //v2/ HTTP/1.0” 301 0 “” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”
192.168.1.1 - - [09/Jan/2019:15:06:48 -0500] “GET //v2/ HTTP/1.0” 301 0 “” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”
192.168.1.1 - - [09/Jan/2019:15:06:48 -0500] “GET //v2/ HTTP/1.0” 301 0 “” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”
192.168.1.1 - - [09/Jan/2019:15:06:48 -0500] “GET //v2/ HTTP/1.0” 301 0 “” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”
192.168.1.1 - - [09/Jan/2019:15:06:48 -0500] “GET //v2/ HTTP/1.0” 301 0 “” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”
192.168.1.1 - - [09/Jan/2019:15:06:48 -0500] “GET //v2/ HTTP/1.0” 301 0 “” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”
192.168.1.1 - - [09/Jan/2019:15:06:49 -0500] “GET //v2/ HTTP/1.0” 301 0 “” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”
192.168.1.1 - - [09/Jan/2019:15:06:49 -0500] “GET //v2/ HTTP/1.0” 301 0 “” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”
192.168.1.1 - - [09/Jan/2019:15:06:49 -0500] “GET //v2/ HTTP/1.0” 301 0 “” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”
192.168.1.1 - - [09/Jan/2019:15:06:49 -0500] “GET //v2/ HTTP/1.0” 301 0 “” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”
192.168.1.1 - - [09/Jan/2019:15:06:49 -0500] “GET //v2/ HTTP/1.0” 301 0 “” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”
192.168.1.1 - - [09/Jan/2019:15:06:49 -0500] “GET //v2/ HTTP/1.0” 301 0 “” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”
192.168.1.1 - - [09/Jan/2019:15:06:49 -0500] “GET //v2/ HTTP/1.0” 301 0 “” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”
192.168.1.1 - - [09/Jan/2019:15:06:49 -0500] “GET //v2/ HTTP/1.0” 301 0 “” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”

Thanks for the help.

I guess you need some more settings for the proxy header. Here is what I’m using:

registry_external_url “https://registry.example
gitlab_rails[‘registry_enabled’] = true
registry[‘enable’] = true
registry_nginx[‘enable’] = true
registry_nginx[‘listen_port’] = 5001
registry_nginx[‘listen_https’] = false
registry_nginx[‘proxy_set_headers’] = {
“Host” => “$http_host”,
“X-Real-IP” => “$remote_addr”,
“X-Forwarded-For” => “$proxy_add_x_forwarded_for”,
“X-Forwarded-Proto” => “https”,
“X-Forwarded-Ssl” => “on”
}

and the settings for nginx

location / {
proxy_read_timeout 300;
proxy_connect_timeout 300;
proxy_redirect off;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Frame-Options SAMEORIGIN;
proxy_set_header X-Forwarded-Ssl on;
proxy_pass http://gitlab_registry_backend;
}

This works for me with the latest release.

1 Like

Thanks for the help. Ultimately, the problem I had was due to my proxy_pass setting in nginx.

I had this:
proxy_pass https://192.168.0.236:4567/$request_uri;

What I noticed in the logs was that the 301 was redirecting to //V1 when trying to connect to the registry. When I removed the “/request_uri” from the proxy pass, the 301 redirects stopped. So my setting now looks like:

proxy_pass https://192.168.0.236:4567