Go 来自xx.xx.xx.xx的TLS握手错误：14333:EOF

我在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文件

由于此错误不断出现，并且在我启动服务器时，终端中就出现了此错误，我认为VM中存在一些配置问题

请建议我可以在这里查看哪些内容

注意：此错误特定于Go。我在同一台服务器上的同一个端口上测试了NodeJS中的相同证书。而且效果很好。

---

此外，错误消息中的IP是反向代理服务器WAF的IP，该服务器正在继续监视web应用程序服务器的运行状况

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

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

那个港口有什么特别之处吗？试着运行nc-l-p 9001，看看那些未识别的连接是否也会发生

运行tcpdump并查看是否有来自进行这些连接的客户端的任何传入流量：TLS mchinery报告的文件末尾的EOF很可能意味着这些客户端在TLS握手过程中的某个地方关闭了连接，而服务器希望从它们那里读取一些数据。 这暗示这些客户机实际上并不期望在他们打开的连接中看到TLS协议；他们可能会发送一些明文，所以你可以偷看一下

谷歌搜索9001端口暗示它用于某些ETL服务管理器协议，不管它是什么。提示9001上的流量可能与VoIP有关

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

---

使用openssl s_client-msg或等效工具查看完整的TLS交换。从你提供的稀缺信息来看，一方在收到不喜欢的东西后决定停止交谈。问题是，当我从笔记本电脑浏览器点击url时，它工作正常，没有任何证书错误。但是在虚拟机内部，这个错误不断地出现在日志中。所以这个请求是从某个地方来的，但我不明白是怎么来的。我的linux虚拟机运行在代理服务器后面，这就是我所知道的。它位于IBM云中。是否有可能自动发出此请求？