Curl "Connection refused" caused by SSL config

Hi all,

I have a strange problem with nginx:
I tried to harden the TLS stack by setting default to recommended values
from but one server
has to
keep backward compatibility – so I set it up as

http {
ssl_protocols TLSv1.1 TLSv1.2;
ssl_ciphers …
ssl_prefer_server_ciphers on;

server {
listen 443 spdy;
server {
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers …
ssl_prefer_server_ciphers on;

listen 443 spdy;


Problem is that starts freezing up randomly after a few
seconds – though sometimes comes back for a short while.
curl from outside reports error as “connection refused”; using curl
localhost:443 responds properly with “* SSL: no alternative certificate
subject name matches target host name ‘localhost’”
CPU usage is not much different from older config; there are no obvious
errors in error_log.

Problem goes away if http-level ssl config is commented out
especially). I think that indicates this config is not properly parsed
the “server” level (does not override http level?)
Seems that I can use the http-level config inside server config
without interfering, but I’d like it to be config default instead.

Other notes: 2 nginx hosts in questions are behind a hardware load

Posted at Nginx Forum:,257064,257064#msg-257064

Also noticed that http-level config causes to show errors on

Posted at Nginx Forum:,257064,257065#msg-257065

So it looks like the ssl config is valid per-port only. If I set up a
on a different port with different ssl config, it works.
Is this a bug or is it by design?

Posted at Nginx Forum:,257064,257086#msg-257086

“Connection refused”, generally means that your server (sometimes this
be a firewall too - although firewalls tend to more often just silently
packets) is sending a RST packet to an attempt to connect. Check with
netstat and see if Nginx is bound to your public IP on :443

As for your question on SSL config – it is valid in both the http and
server context, ref.

Your configuration seems to be that you have one certificate, and two
virtual hosts, that respond to different host-headers.

for the first one, you probably mean:


or do you mean to have it as a catch-all for “*”

Are you only trying to enable SSL3 for “” and have only
“TLSv1.1 TLSv1.2” for the other one?

Lastly, maybe give some more stuff to work with here, like your actual
and your full configuration.

Posted at Nginx Forum:,257064,257088#msg-257088

Thanks Maxim, that explains it
Would be nice if documentation mentioned this fact, or nginx would spit
some errors about the conflicting config :wink:

Posted at Nginx Forum:,257064,257107#msg-257107


On Thu, Mar 05, 2015 at 09:58:37PM -0500, Fry-kun wrote:

So it looks like the ssl config is valid per-port only. If I set up a server
on a different port with different ssl config, it works.
Is this a bug or is it by design?

This is by design. Before some protocol-specific handshake
happens, it is not possible to tell which virtual server client is
going to request. Therefore, the default server context (and
corresponding options) are used before the handshake.

In this particular case, you are trying to enable SSLv3 for a
virtual server. This is not possible at all even in theory:
there is no SNI extension in SSLv3, and requested virtual server
will be known only after reading an HTTP request. But it won’t be
possible to send an HTTP request as SSLv3 is disabled in the
default server, and therefore the SSL handshake will fail.

See here for some additional details about configuring SSL in

Maxim D.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs