我今天调试了一个SSL问题，也导致了同样的write:errno=104错误。最后我发现这个行为的原因是服务器需要SNI（servername TLS扩展）才能正常工作。为openssl提供-servername选项可以使它成功连接：

openssl s_client -connect domain.tld:443 -servername domain.tld

15841:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:
...
SSL handshake has read 0 bytes and written 121 bytes

这是一个握手失败。另一端关闭了连接，没有发送任何数据（“读取0字节”）。这可能是因为另一端根本不讲SSL。但我在坏掉的SSL实现上看到过类似的错误，它不理解较新的SSL版本。如果您通过向s_client的命令行添加-ssl3获得SSL连接，请尝试。

我遇到write:errno=104试图使用openssl s_client测试连接到启用SSL的RabbitMQ代理端口。
这个问题原来只是因为用户RabbitMQ没有证书文件的读取权限，RabbitMQ中几乎没有有用的日志记录。

在我的例子中，ssl证书没有为所有站点配置（仅为非www版本重定向到的www版本配置）。我使用Laravel forge和Nginx Boilerplate config
我为我的nginx站点配置了以下内容：

/etc/nginx/可用站点/timtimer.at

server {
    listen [::]:80;
    listen 80;
    server_name timtimer.at www.timtimer.at;

    include h5bp/directive-only/ssl.conf;

    # and redirect to the https host (declared below)
    # avoiding http://www -> https://www -> https:// chain.
    return 301 https://www.timtimer.at$request_uri;
}

server {
    listen [::]:443 ssl spdy;
    listen 443 ssl spdy;

    # listen on the wrong host
    server_name timtimer.at;

    ### ERROR IS HERE ###
    # You eighter have to include the .crt and .key here also (like below)
    # or include it in the below included ssl.conf like suggested by H5BP

    include h5bp/directive-only/ssl.conf;

    # and redirect to the www host (declared below)
    return 301 https://www.timtimer.at$request_uri;
}

server {
    listen [::]:443 ssl spdy;
    listen 443 ssl spdy;

    server_name www.timtimer.at;

    include h5bp/directive-only/ssl.conf;

    # Path for static files
    root /home/forge/default/public;

    # FORGE SSL (DO NOT REMOVE!)
    ssl_certificate /etc/nginx/ssl/default/2658/server.crt;
    ssl_certificate_key /etc/nginx/ssl/default/2658/server.key;

    # ...

    # Include the basic h5bp config set
    include h5bp/basic.conf;
}

因此，在将以下部分移动（剪切和粘贴）到 /etc/nginx/h5 bp/directive-only/ssl.conf 文件后，一切都按预期运行：

# FORGE SSL (DO NOT REMOVE!)
ssl_certificate /etc/nginx/ssl/default/2658/server.crt;
ssl_certificate_key /etc/nginx/ssl/default/2658/server.key;

因此，如果您只直接调用www版本，仅为www版本指定密钥是不够的！

当github.com我们的代理用他们的自签名证书重写HTTPS连接时，我也试图访问www.example.com，得到了下面的消息：
无对等证书可用未发送客户端证书CA名称
在我的输出中还有：
方案：TLSv1.3
我添加了-tls1_2，它工作正常，现在我可以看到它在传出请求上使用的CA。
openssl s_client -connect github.com:443 -tls1_2

我也遇到过类似的问题，根本原因是发送IP不在接收服务器的白名单IP范围内，所以所有的通信请求都被接收站点杀死了。

我也遇到过同样的问题。但是使用IP很好;我在/etc/hosts中指定了ip host
使用IP工作正常，但主机不能