GitLab behind Reverse Proxy does not work


When Gitlab ce nginx server is listening to http (80) but is behind a reverse proxy server which is listening to https (443), it does not not work and no issue is found about that.

–HTTPS—> reverse proxy ( —HTTP—> gitlab server (

When there’s no reverse proxy and gitlab server is listening to http, it’s working.

With reverse proxy https is behind, the user’s connection box is displayed but when an user tries to connect, it happens 404 gitlab error!

Please help us !


default installation but with this config :

external_url ‘’
nginx[‘listen_port’] = 80
nginx[‘listen_https’] = false
gitlab_rails[‘trusted_proxies’] = [‘192.168.x.xx’,‘192.168.x.xy’]
nginx[‘proxy_set_headers’] = {
“Host” => “”,
“X-Forwarded-Proto” => “https”,
“X-Forwarded-Ssl” => “on”

System information

Current User: git
Using RVM: no
Ruby Version: 2.7.2p137
Gem Version: 3.1.4
Bundler Version:2.1.4
Rake Version: 13.0.3
Redis Version: 6.0.10
Git Version: 2.29.0
Sidekiq Version:5.2.9
Go Version: unknown

GitLab information
Version: 13.10.0
Revision: 5eafdaf7b07
Directory: /opt/gitlab/embedded/service/gitlab-rails
DB Adapter: PostgreSQL
DB Version: 12.5
SSH Clone URL:
Using LDAP: yes
Using Omniauth: yes
Omniauth Providers:

GitLab Shell
Version: 13.17.0
Repository storage paths:

  • default: /var/opt/gitlab/git-data/repositories
    GitLab Shell path: /opt/gitlab/embedded/service/gitlab-shell
    Git: /opt/gitlab/embedded/bin/git

/var/log/gitlab/nginx/gitlab_access.log - - [26/Apr/2021:18:31:14 +0200] “GET /users/sign_in HTTP/1.1” 302 106 “” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.72 Safari/537.36” - - - [26/Apr/2021:18:31:15 +0200] “GET /users/ HTTP/1.1” 404 28614 “” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.72 Safari/537.36” -


[ActiveJob] Enqueued ActionMailer::MailDeliveryJob (Job ID: ff2d0722-c92f-4c0e-aa6c-89ed739f8acb) to Sidekiq(mailers) with arguments: “Notify”, “unknown_sign_in_email”, “deliver_now”, {:args=>[#<GlobalID:0x00007f1d45e785b0 @uri=#<URI::GID gid://gitlab/User/1>>, “”, Mon, 26 Apr 2021 15:36:51 UTC +00:00]}
Completed 302 Found in 268ms (ActiveRecord: 78.9ms | Elasticsearch: 0.0ms | Allocations: 39298)
[ActiveJob] [ActionMailer::MailDeliveryJob] [ff2d0722-c92f-4c0e-aa6c-89ed739f8acb] Performing ActionMailer::MailDeliveryJob (Job ID: ff2d0722-c92f-4c0e-aa6c-89ed739f8acb) from Sidekiq(mailers) enqueued at 2021-04-26T15:36:51Z with arguments: “Notify”, “unknown_sign_in_email”, “deliver_now”, {:args=>[#<GlobalID:0x00007f77c1ec3138 @uri=#<URI::GID gid://gitlab/User/1>>, “”, Mon, 26 Apr 2021 15:36:51 UTC +00:00]}
Started GET “/users/” for at 2021-04-26 17:36:51 +0200
Processing by ApplicationController#route_not_found as HTML
Parameters: {“unmatched_route"=>"users”}

Hi, any reason for putting gitlab behind a https proxy? Gitlab can do HTTPS without a https proxy. It can use letsencrypt certificates, or you can even put your own certificates and use them with gitlab.

Otherwise, nginx needs to know it’s behind a proxy, and needs to know how to reply to it. And then things will get complicated, because then you won’t be able to do that really with the embedded nginx, and you will then have to configure a separate nginx outside of gitlab on the same server to then deal with that. It also needs to know what to reply with, since you are effectively doing what is called “SSL offload”, so it would have to rewrite all links, and the HTTPS proxy should send the appropriate headers such as X-Forwarded-For and X-Forwarded-Proto. You could probably just do it easier by doing just HTTPS via the proxy, so:

HTTPS → reverse proxy → HTTPS → gitlab server

that way you won’t need to worry with separating nginx from gitlab, and configuring it to deal with the SSL offload, since it will just reply with HTTPS links to the proxy.

This is all explained in the docs anyway:

just search on the page for “reverse proxy”.