Hi all
I found this thread when I was looking for “ready to go” information about running gitlab behind an already existing apache2 server (running on ports 80 and 443 with SSL enabled - using let’s encrypt).
This apache2 server is used for a lot of things (so it cannot be removed and replaced by gitlab).
SSL enabled and forced: every http request is forced https by apache.
Here is the “ready to go” information!
First you have to enable apache2 “proxy” mods:
a2enmod proxy
a2enmod proxy_http
service apache2 restart
Then you have to create a config file for redirecting URL which begins with /gitlab to the real gitlab server (which will be installed on the same machine, in this example, listening on port 81)
/etc/apache2/conf-available/proxy-to-gitlab.conf:
ProxyRequests off
ProxyPass "/gitlab" "http://127.0.0.1:81/gitlab" retry=0
ProxyPassReverse "/gitlab" "http://127.0.0.1:81/gitlab"
Then enabling this configuration file by playing
a2enconf proxy-to-gitlab
service apache2 restart
(this creates a link agains this file into conf-enabled folder, and starting from now, apache2 is ready).
In the “gitlab” side, after installation, into /etc/gitlab/gitlab.rb:
external_url 'http://real-apache2-url.com/gitlab'
gitlab_rails['trusted_proxies'] = ['127.0.0.1']
nginx['listen_addresses'] = ['127.0.0.1']
nginx['listen_port'] = 81
nginx['real_ip_trusted_addresses'] = ['127.0.0.1']
nginx['real_ip_header'] = 'X-Forwarded-For'
nginx['real_ip_recursive'] = 'on'
Mind the “http”: it’s much easier to avoid gitlab messing with https stuff since apache2 is already doing everything fine, in a transparent way so that gitlab doesn’t have to handle this.
After that, running “gitlab-ctl reconfigure” and everything worked fine!
Real user’s IP addresses are correctly seen, gitlab isn’t “https aware” but every http link is forced https by apache (even git clone commands) so that’s all perfect 
and of course, what was on the apache2 server is still working.