Two sites listening on same port simultaneously with different location (context) not workig

Reinis Rozitis r at roze.lv
Tue Feb 18 11:16:18 UTC 2020


> Now while accessing my VM ip http://x.y.z.a, I am getting "403 Forbidden"
> error in the browser. However gitlab still working. How to get both the sites
> working listening on port 80 but with different context of location?

First of all you should check the error log to see why the 403 is returned and it usually gives the idea what is happening and which server {} block nginx is using and what file/location is being served.


> While testing gitlab, I deleted default file soft link from nginx sites-enabled.
> I created the soft link again the configuration is as follows: Note that default_server is removed her and location path is "/"

Second, it's a bit unclear what is your current nginx configuration is (nginx -T should display the "compiled" configuration with all the includes)
(depending on where 'include sites-enabled/*' is placed in the main config the behavior can change)

But in general virtualhosts (sites listening on the same ip/port) are distinguished by the 'server_name' - if a non-defined domain (or bare ip) is pointed to nginx - then either the virtualhost with 'default' / 'default_server'  OR by order in the configuration first server {} block is used.

Most likely your gitlab server{} comes first and when you open your vm ip http://x.y.z.a  nginx is trying to use /opt/gitlab/embedded/service/gitlab-rails/public but since there is probably no index file and/or maybe has no permissions 403 is returned.



Each server {} uses its own location blocks .. So if you want to have both '/' and '/gitlab'  from the same ip/host you need to place them in the same server{}. 

Somethine like:

server {
  listen 0.0.0.0:80;
  listen [::]:80;
  root /var/www/html;
...
  location / {
    try_files $uri $uri/ =404;
  }

  location /gitlab {
    proxy_pass http://gitlab-workhorse;
    ...
  }
}

p.s. from my own experience it's more simple to host Gitlab from own (sub)domain rather than to configure as a subdirectory.

rr 



More information about the nginx mailing list