Backup with new external_url still points to old name

Hi all,

I’d like to migrate a gitlab installation from RH6 to RH7.
the installation is using a DNS alias “”.
I have the saem gitlab version in both servers (8.16.5-ce.1 omnibus install) and I’ve restored a backup from the old server to the new one. So far so good.
In order to check that everything looks the same in the new server I’ve changed the external_url in the new server (/etc/gitlab/gitlab.rb) so it matches the server hostname:

external_url ‘
external_url ‘https://new_hostname’

then reconfigure the service with the command:

gitlab-ctl reconfigure

When I open the browser and I enter the URL ‘https://new_hostname’ I get redirected to (old server still in use).

How can I make the new installation to not redirect me to the git alias?


1 Like

Hi pelacables,

I would request you to take output of the below commands and post it here for better understanding of your problem.

These commands can be run on your production environment: (run as root)

to check hostname of machine:

to verify hostname of machine:
cat /etc/hosts

to check DNS on your machine and the machines you are testing your URL:
nslookup your domain name

to check all gitlab component are working or not:
gitlab-ctl status

to check url for GitLab:
cat /gitlab/gitlab.rb | grep external_url

to check port is open for GitLab or not:
netstat -tlpn

to check selinux status:

to check any firewall enabled or not:
iptables --list

After running all the above command please follow below steps to use the new server external_url on your browser because sometime gitlab start misbehaving after the upgradation to new version of gitlab :

Step 1:

Please enter the external_url on /etc/gitlab/gitlab.rb file as you have already given the external_url so there is no need.

to reconfigure gitlab after giving external_url
gitlab-ctl reconfigure

Step 2:
After that run the restart command to restart each commonent of gitlab
gitlab-ctl restart

I hope all the above command will help you.
Please feel free and share the output of the above command and also reply if you have any query.



first of all, thanks for your answer.

The hostname and network from the server is properly set. Selinux is disabled and the firewall stopped.
I’ve also followed the general documentation about external_url in gitlab.rb + reconfigure (and extra restart/ reboot). Nothing helps.

The relevant logs when accessing http://new_hostname show the redirect:

==> /var/log/gitlab/gitlab-rails/production.log <==
Started GET “/” for X.Y.Z at 2018-03-16 09:36:33 +0100
Processing by RootController#index as HTML
Redirected to
Filter chain halted as :redirect_unlogged_user rendered or redirected
Completed 302 Found in 4ms (ActiveRecord: 0.0ms)
==> /var/log/gitlab/gitlab-rails/production_json.log <==
==> /var/log/gitlab/gitlab-workhorse/current <==
2018-03-16_08:36:33.35611 new_hostname @ - - [2018-03-16 09:36:33.3411427 +0100 CET m=+2788.063608676] “GET / HTTP/1.1” 302 95 “” “Mozilla/5.0 (Win
dows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36” 0.014898

After some more googling I’ve found someone with the same issue I’m facing:

If I go to ‘https://new_hostname/users/sign_in’ I can see the new installation and log into the new server.

So, the nginx conf for the “/” location is the source of the problem:

location / {
proxy_cache off;
proxy_pass http://gitlab-workhorse;

and the gitlab-workhorse is doing (somehow) the redirect.

Funny fact is that it happened to me with version 8, 9 and 10.


One more thing:

  1. I go to https://new_server/users/sign_in (this url works)

  2. I log in and I get redirected to

  3. if I visit https://new_server/ once I’ve logged in, then it works as expect without redirecting me to


The behavior you describe in a “normal bug”, affecting every Gitlab version.
That is because the “settings” tab of the admin is taking over : more precisely, in your /admin/application_settings page, the “Home page URL” and “After sign out path” are applied.

Two workarounds :

  • Empty the parameters before your migration
  • After migration : log in through https://new_server/users/sign_in ; you are redirected to the old url. Go back to https://new_server/admin/application_settings and change the parameters.

Had the same problem. Did “throw away” 1 hour of work. Maybe this “normal bug” shoud me somehow mentioned in the documentation.

This seriously has saved my day. Thank you very very much.
And I agree, this should has been mentioned somewhere in gitlab documentation related to migrating gitlab instance from one server to another or domain change.

This is an absolutely common standard use case and should definitely be mentioned in the docs, resp. the gitlab backup/restore section - i actually can not believe that this is missing under the dozens of topics there.

Thanks for saving me a lot of trouble (and time) by pointing this out here!

PS: this still applies to version 12.3.5

For those like me who’ve wasted hours trying to find the relevant setting in 13.5, it’s under Admin / Settings / General / Sign-in restrictions / Home page url.