nginx not forwarding requests to backend servers.
Brian Pugh
project722 at gmail.com
Wed Jul 27 19:02:23 UTC 2016
Reinis Rozitis said:
Also for secure backend connection you should enable proxy_ssl.
Reading https://www.nginx.com/resources/admin-guide/nginx-tcp-ssl-upstreams/
should
probably be a good start.
=====================================
Is this a feature I can get without having to purchase nginx plus? If my
nginx server has an SSL cert loaded that validates the hostnames for the
backend servers and my backend servers also have the same cert and
communications are going over port 443 why would I need to do anything else?
On Wed, Jul 27, 2016 at 12:16 PM, Brian Pugh <project722 at gmail.com> wrote:
> Ok. I was able to get it working by changing this:
>
> proxy_pass http://ssl_myapplicationsite.net
> <http://ssl_test-resolve.cspire.net/>;
>
> to this:
>
> proxy_pass *https*://ssl_myapplicationsite.net
> <http://ssl_test-resolve.cspire.net/>;
>
>
>
> On Wed, Jul 27, 2016 at 12:07 PM, Brian Pugh <project722 at gmail.com> wrote:
>
>> Still not working.
>>
>> Logs show:
>>
>> 2016/07/27 11:59:35 [warn] 28038#28038: *3 upstream server temporarily
>> disabled while reading response header from upstream, client:
>> 192.168.254.202, server: myapplicationsite.net, request: "GET /
>> HTTP/1.1", upstream: *"http://192.168.155.120:443/
>> <http://192.168.155.120:443/>"*, host: "myapplicationsite.net"
>>
>> Why does it show http:// with :443 here?
>>
>> Here is my updated config:
>>
>> http {
>> upstream mysiteapplication.net {
>> # Use ip hash for session persistance
>> ip_hash;
>> server backendappsite1:80;
>> server backendsiteapp2:80;
>> server backendsiteapp3:80;
>>
>> # The below only works on nginx plus
>> #sticky route $route_cookie $route_uri;
>> }
>> upstream ssl_mysiteapplication.net.net {
>> # Use ip hash for session persistance
>> ip_hash;
>> server backendappsite1:443;
>> server backendappsite2:443;
>> server backendappsite3:443;
>>
>> # The below only works on nginx plus
>> #sticky route $route_cookie $route_uri;
>> }
>>
>> Crasyangel - I am not sure where I am supposed to put this:
>>
>> u.default_port = 80; in ngx_http_upstream_server
>>
>> I tried it inside my http upstream block and got a message about
>>
>> unknown directive "u.default_port"
>>
>> Here is my updated default.conf:
>>
>> server {
>> listen 443 ssl;
>> server_name myapplicationsite.net;
>> keepalive_timeout 70;
>>
>> ssl_certificate /appssl/fd.crt;
>> ssl_certificate_key /appssl/lb.key;
>> ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
>> ssl_ciphers HIGH:!aNULL:!MD5;
>>
>> location / {
>> proxy_pass http://ssl_test-resolve.cspire.net;
>> proxy_set_header HOST test-resolve.cspire.net;
>>
>> }
>> }
>>
>>
>> On Wed, Jul 27, 2016 at 11:18 AM, Reinis Rozitis <r at roze.lv> wrote:
>>
>>> : "myapplicationsite.net"
>>>> 2016/07/27 10:54:05 [warn] 27491#27491: *3 upstream server temporarily
>>>> disabled while connecting to upstream, client: 192.168.254.202, server:
>>>> myapplicationsite.net, request: "GET / HTTP/1.1", upstream: "
>>>> http://192.168.155.120:80/", host: "myapplicationsite.net"
>>>>
>>>
>>> Why is it trying to connect to my servers over port 80? I need to pass
>>>> it over on 443. How can I accomplish this? Even if I change the proxy pass
>>>> to https in the logs it still trys
>>>>
>>>
>>> As you don't specify the port in upstream {} block nginx uses the
>>> default which is 80 (
>>> http://nginx.org/en/docs/http/ngx_http_upstream_module.html#server )
>>>
>>> Also for secure backend connection you should enable proxy_ssl.
>>>
>>> Reading
>>> https://www.nginx.com/resources/admin-guide/nginx-tcp-ssl-upstreams/
>>> should probably be a good start.
>>>
>>>
>>> rr
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Jul 27, 2016 at 10:42 AM, Reinis Rozitis <r at roze.lv> wrote:
>>> Can anyone give me an example config of what it would look like in both
>>> nginx.conf and default.conf using the names/info I have provided?
>>>
>>> It seems you have taken the default configuration example but if you use
>>> nginx as a balancer without serving any .php (or other) files you actually
>>> don't need those *.php etc locations - a single location / {} will do the
>>> job (means all requests go to backends).
>>>
>>> For example:
>>>
>>>
>>> http {
>>> upstream myappliationsite.net {
>>> ip_hash;
>>> server backendappsite1.net;
>>> server backendappsite2.net;
>>> server backendappsite3.net;
>>> }
>>>
>>> server {
>>> listen 80;
>>> listen 443 ssl;
>>>
>>> server_name myappliationsite.net;
>>>
>>> location / {
>>> proxy_pass http://myappliationsite.net;
>>> proxy_set_header HOST myappliationsite.net;
>>> }
>>> }
>>>
>>>
>>>
>>> _______________________________________________
>>> nginx mailing list
>>> nginx at nginx.org
>>> http://mailman.nginx.org/mailman/listinfo/nginx
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> nginx mailing list
>>> nginx at nginx.org
>>> http://mailman.nginx.org/mailman/listinfo/nginx
>>> _______________________________________________
>>> nginx mailing list
>>> nginx at nginx.org
>>> http://mailman.nginx.org/mailman/listinfo/nginx
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20160727/972e85ed/attachment.html>
More information about the nginx
mailing list