No CORS Workaround - SSL Proxy

[Maxim Dounin]

Hello!

On Wed, Jul 02, 2014 at 02:37:17PM +0400, Maxim Dounin wrote:

> Hello!
> 
> On Tue, Jul 01, 2014 at 05:58:33PM +0000, Eric Swenson wrote:
> 
> > On 6/22/14, 7:32 AM, "Maxim Dounin" <mdounin at mdounin.ru> wrote:
> > 
> > >If there is nothing in error logs, and you are getting 502 errors,
> > >then there are two options:
> > >
> > >1. The 502 errors are returned by your backend, not generated by
> > >   nginx.
> > >
> > >2. You did something wrong while configuring error logs and/or you
> > >   are looking into a wrong log.
> > >
> > >In this particular case, I would suggest the latter.
> > 
> > I¹ve verified that my error log are configured fine ‹ I do get errors
> > reported in my configured error log ‹ but nothing at the time that nginx
> > returns 502 errors to the client.
> 
> As nginx has lots of options to control error logging (logging 
> level based filtering, as well as per-server and per-location 
> error logs), it's not enough to check that some errors are logged 
> to make sure logging is configured properly.
> 
> Simplest way to configure logs properly is to comment out all 
> error_log directives, and add error_log at global level, with 
> desired logging level.  In this case, logging at "error" level 
> should be enough, i.e., the following should do the trick:
> 
> error_log /path/to/log error;
> 
> (At global level, i.e., at the top of your nginx.conf file.  And 
> don't forget to comment out all other error_log directives.)

Correction: in case of proxy to https, there is one case when the 
error is reported at "info" level ("peer closed connection in SSL 
handshake"), so "info" level logging is needed to see it.

(This looks like a bug and should be fixed, while talking to 
upstream servers proper logging level for SSL handshake errors is 
"error".)

> > I¹ve checked the upstream server¹s logs, even when configured with debug
> > logging, and never see any requests making it to the upstream server when
> > nginx returns a 502 to the client.
> > 
> > If the issue were with the upstream server, why is it that simply
> > restarting nginx causes everything to proceed normally. I never have to
> > touch the upstream server (which, by the way is serving other requests
> > successfully from other proxies at the same time as the nginx proxy that
> > returns 502s is doing do.
> 
> The fact that reastarting nginx fixes things indicates that the 
> problem is likely caused by connections already established by 
> nginx to the upstream server in question.  And restarting nginx 
> fixes things by closing these connections.

If the problem is indeed during SSL handshake, it may be caused by 
a cached session peer starts to dislike for some reason.  
Switching off "proxy_ssl_session_reuse" could help.  See also this 
answer, which may be related:

http://mailman.nginx.org/pipermail/nginx/2014-July/044329.html

-- 
Maxim Dounin
http://nginx.org/