On Wed, Feb 22, 2017 at 06:29:56AM +0100, Filip Francis wrote: Hi there,
I haven't tested any of this, but... > I am trying to set-up a reverse proxy with nginx so that based on > the server_name it goes to the correct backend. That should be straightforward; and it looks to me like you almost have it working. > when user type xxxx.yyy.be as normal http it redirects to https and > then forwards it to the backend nummer 1 It may be worth being explicit there: http://xxxx.yyy.be is redirected to https://xxxx.yyy.be https://xxxx.yyy.be is proxy_pass'ed to backend1 > but when user type zzzz.yyy.be also as normal http it redrects it to > https and forwards it to the correct backend (so here it would be > backend nummer 2) And the same for zzzz.yyy.be, but eventually to backend2. > so in sites-enabled i put several files that is being loaded but > nothing is working Does "nothing is working" include "curl -v http://xxxx.yyy.be"; getting something other than a 301 redirect to https://xxxx.yyy.be ? If so - what does it get instead? > include /opt/local/etc/nginx/sites-enabled/*; > here is the content: > > owncloud: > server { > listen 443 ssl http2; ssl is on, but there is no "default_server" set explicitly here. > and mattermost: > server { > listen 443; ssl is not on, and there is no "default_server" set explicitly here. Alphabetically, I think that this server{} will be the default for any connections to port 443, and I'm not sure what will happen when "ssl" is not set here but is set elsewhere on a port 443 listener. > This is working (more or less) but if i start moving the ssl bit > into the owncloud or mattermost its simply is not working any more I don't understand what you mean by this, I'm afraid. The config you show does work, but a config you do not show does not work? Or something else? > getting each time that i type http://zzzz.yyy.be i get 400 bad > request The plain HTTP request was sent to HTTPS port If the problem is "missing ssl on the mattermost listen directive", then I would expect a https request to be going to a http port. http request to a https port looks like it would need your upstream (192.168.1.95:8065) to be listening for https. Just for clarity, could you show the responses you get for a "curl -v" request to the first http:// address, and then to the (presumably) returned 301 Location? That may make it more obvious what is happening, compared to what should be happening; and may make the solution clear to somebody. Cheers, f -- Francis Daly fran...@daoine.org _______________________________________________ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
