Can you try with go1.8rc1? It looks like you are triggering the problem described in #17037, which was fixed in go1.8 by 5a59b66, so you shouldn't see the EOFs with go1.8, but actual alerts.

What version of Go are you using (go version)?

go version go1.8rc1 linux/amd64

What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GORACE=""
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build900657989=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"

What did you see?

Same problem persists

@ALTree is there any way I can help with issue?

With "same problem persists" you mean that you're still seeing EOFs during handshakes on go1.8?

In my Go server logs there are many lines like these (Go 1.8 beta 2, too):

2017/01/11 20:55:03 http2: server: error reading preface from client *.*.153.123:14777: timeout waiting for client preface
2017/01/11 20:57:28 http: TLS handshake error from *.*.92.45:50361: EOF

Dunno if it is relevant.

With "same problem persists" you mean that you're still seeing EOFs during handshakes on go1.8?

Yes

@ALTree I have investigated an issue.

1. I was wrong that this problem is Connection establishing issue
2. It comes from reading data

Problem comes from here:
https://github.com/golang/go/blob/master/src/crypto/tls/conn.go#L1167

Data is there, but alert is also coming immediately with data, probably because nature of application is
server gets request, responds and immediately closes connection (1line, less than 100bytes).

fix is not checking err first, instead testing whether we got data and then check for error

n, err = conn.Read(buf)
if n != 0 {
	println(string(buf[:n]))
} 
if err != nil {
	log.Println(n, err)
	return
}

Maybe this should be documented

It is already documented at https://golang.org/pkg/io/#Reader ...

Callers should always process the n > 0 bytes returned before considering the error err.

Sounds like there's nothing to do here. Closing. Let me know if I misunderstand.