Multiple TLS servers end in data race

Hi, I’m trying to run a http server and a tcp server(cache.RemoteTlsConnHandler) in the same go program.
The program hosts a webserver instance and a tcp server instance. Both run on different ports and with https enabled. The code cutout below shows is running in the main thread. There should be no shared values(but I’m almost certain that there are none ?!) between the net/http and my tcp server(cache.RemoteTlsConnHandler). next it creates the key pair inits the server and config and starts the tls conn Server. When I remove one of the server inits(remote cache or ListenAndServe) the race condition vanishes. The condition itself is pretty useless because the read is not available and the write is always outside of my code but in the Go net/http stack. How do I proceed debugging something like that? (I know that there is no testable example but I did not manage to recreate the problem, here is a link to the codebase maybe that gives a bit more context.) The Stacktrace is repeating itself (I think at least) and the race condition appears only when I interact with one of the two instances.

  // params: port int, bindAddress string, pwHash string, dosProtection bool, serverCert string,     serverKey string
    go func(cache cache.Cache, syncPort int, address string, token string, dosProtection bool, tlsCert string, tlsKey string) error {
        return cache.RemoteTlsConnHandler(syncPort, address, token, dosProtection, tlsCert, tlsKey)
    }(instance.cache, instance.syncPort, instance.address, instance.token, false, instance.tlsCert, instance.tlsKey)

    cert, err := tls.X509KeyPair([]byte(instance.tlsCert), []byte(instance.tlsKey))
    if err != nil {
        return err
    }

    tlsConnServer := http.Server {
        Addr:      instance.address+":"+strconv.Itoa(instance.fileServerPort),
        TLSConfig: &tls.Config{
            Certificates: []tls.Certificate{cert},
        },
    }
    if err := tlsConnServer.ListenAndServeTLS("", ""); err != nil {
        return err
    }

The stack trace: https://pastebin.com/6V0cjHc5

greets