我有一个networking服务器背后的nginx和一切运作良好，除了一件事。 我试图确认一个亚马逊的SNS订阅，需要发布一些参数（与确认的url）到我的网站成为活跃之前。 我所有的尝试失败了，我认为这是用AWS比预期更长的时间…直到我打开nginx日志，看看是否有任何请求正在发送当我看到这个严重错误：
[crit] 6#6: *13 SSL_do_handshake() failed (SSL: error:14076102:SSL routines:SSL23_GET_CLIENT_HELLO:unsupported protocol) while SSL handshaking, client: 54.239.98.103, server: 0.0.0.0:443
由于它很重要，它不会让请求去networking服务器，并确认我的SNS。
任何想法可能是什么原因呢？ 另外，这里是我的nginx conf：
worker_processes auto; error_log /dev/stderr info; user nobody nogroup; pid /tmp/nginx.pid; error_log /tmp/nginx.error.log; events { worker_connections 1024; accept_mutex off; } http { include mime.types; default_type application/octet-stream; access_log /dev/stdout; sendfile on; keepalive_timeout 65; gzip on; gzip_disable "MSIE [1-6].(?!.*SV1)"; gzip_vary on; upstream app_server { server unix:/tmp/gunicorn.sock fail_timeout=0; } server { # redirect all http requests to https listen 80; listen [::]:80 ipv6only=on; return 301 https://$host$request_uri; } server { listen 443 ssl spdy; client_max_body_size 4G; server_name www.devcasts.io; keepalive_timeout 5; # Use HTTP Strict Transport Security (HSTS) # v. Django Doc: https://docs.djangoproject.com/en/1.7/topics/security/ # v. https://gist.github.com/plentz/6737338 add_header Strict-Transport-Security "max-age=31536000; includeSubdomains;"; # ssl_session_cache caches session parameters that create the SSL/TLS # connection. This cache, shared among all worker_connections, will # drastically improve later requests since the connection setup # information is already known. As a reference, a 1MB shared cache # can hold approximately 4,000 sessions. As the timeout length is # increased you will need a larger cache to store the sessions. The # default timeout value for ssl_session_timeout is 5 minutes so to # improve performance it can be increased to a several hours. ssl_session_timeout 1d; ssl_session_cache shared:SSL:50m; # Session tickets store information about specific SSL/TLS sessions. # When a client resumes interaction with an application the session # ticket is used to resume the session without re negotiation. As an # alternative to session tickets, session id's can be used. Session # id's map to a specific session stored in the ssl_session_cache via # a MD5 hash. Both mechanisms can be used to shortcut the SSL handshake. ssl_session_tickets on; ssl_dhparam /etc/nginx/ssl/dhparam.pem; location / { try_files $uri @proxy_to_app; } location @proxy_to_app { proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_redirect off; proxy_pass http://app_server; } ssl_certificate /etc/nginx/ssl/devcasts.pem; ssl_certificate_key /etc/nginx/ssl/devcasts.key; ssl_protocols SSLv3 TLSv1.1 TLSv1.2; ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK'; ssl_prefer_server_ciphers on; ssl_stapling on; ssl_stapling_verify on; ssl_trusted_certificate /etc/nginx/ssl/trustchain.crt; resolver 8.8.8.8 8.8.4.4; } }
SSL routines:SSL23_GET_CLIENT_HELLO:unsupported protocol
这意味着客户端尝试使用SSL2进行连接，而您明确禁止它：
ssl_protocols SSLv3 TLSv1.1 TLSv1.2;
这实际上是一件好事。 SSL 2和3是不安全的，正在积极劝阻。 除非需要支持非常老的客户端，否则使用TSL1.0或更高版本应该没问题。