TLS握手失败：收到来自 xx.xx.xx.xx:14333 的EOF

珍惜时间，勤奋学习！今天给大家带来《TLS握手失败：收到来自 xx.xx.xx.xx:14333 的EOF》，正文内容主要涉及到等等，如果你正在学习Golang，或者是对Golang有疑问，欢迎大家关注我！后面我会持续更新相关内容的，希望都能帮到正在学习的大家！

我正在 linux (rhel 7) 中运行 https 服务器。当我启动服务器时，我收到以下错误。

2019/09/04 15:46:16 http: tls handshake error from xx.xx.xx.xx:60206: eof
2019/09/04 15:46:21 http: tls handshake error from xx.xx.xx.xx:31824: eof

此错误在终端中自动且持续出现。 下面是创建 https 服务器的 go 代码 -

package main

import (
    "fmt"
    "net/http"

    "github.com/gin-gonic/gin"
)

func main() {
    fmt.Println("Starting webserver")

    router := gin.Default()
    router.GET("/", func(c *gin.Context) {
        c.JSON(http.StatusOK, gin.H{
            "success": true,
        })
    })

    router.RunTLS(":9001", "server.pem", "server.key")
}

我们已购买并将服务器证书、中间证书和根证书合并到一个文件中，以生成 server.pem 文件。

由于这个错误在我启动服务器后就不断出现在终端中，我认为虚拟机中存在一些配置问题？

请建议我可以在此处检查哪些内容。

注意：此错误特定于 go。我已经在 node js 中使用相同证书在同一服务器上的同一端口上进行了测试。而且效果很好。 此外，错误消息中的 ip 是反向代理服务器 (waf) 的 ip，该服务器持续对 web 应用程序服务器进行运行状况监控。

解决方案

我会从两个角度解决这个问题：

1. 这个 xx.xx.xx.xx 地址是什么？我希望当我启动某个随机软件时，没有任何东西可以单独连接到它，对吗？

2. 9001 端口有什么特别之处吗？尝试运行 nc -l -p 9001 并查看是否也会发生这些未识别的连接。

   运行 tcpdump 并查看是否有来自进行这些连接的客户端的任何传入流量：TLS 机器报告的那些 EOFs（即“文件结尾”）很可能意味着这些客户端（无论它们是什么）关闭了它们的一侧在 TLS 握手期间的某处连接，而服务器期望从中读取一些数据。 这暗示这些客户端实际上并不希望在他们打开的连接中看到 TLS 协议；他们几乎可能会在其中发送一些明文，因此您可以查看它。

3. 谷歌搜索“9001端口”暗示它用于某些“ETL服务管理器”协议——无论它是什么。 This 暗示 9001 上的流量可能与 VoIP 有关。

   我不知道该怎么办，但它可能会给你一些进一步研究的线索。

理论要掌握，实操不能落！以上关于《TLS握手失败：收到来自 xx.xx.xx.xx:14333 的EOF》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！