VLESS + `xtls-rprx-vision`: server forwards an extra TLS record after the splice

Operating system

Linux

System version

Ubuntu 24.04

Installation type

Original sing-box Command Line

If you are using a graphical client, please provide the version of the client.

No response

Version

sing-box version 1.14.0-beta.7

Environment: go1.25.12 linux/amd64
Tags: with_gvisor,with_quic,with_dhcp,with_wireguard,with_utls,with_acme,with_clash_api,with_tailscale,with_ccm,with_ocm,with_cloudflared,with_naive_outbound,with_usbip,with_openvpn,with_openconnect,badlinkname,tfogo_checklinkname0,with_purego
Revision: 3001f038a2198673c0733e0c5fd19d5e3db4fad6
CGO: disabled

Description

Investigated with AI assistance, so the reasoning about the cause may be off in
places. The reproduction below is scripted and was run as shown; the fix is in
use on a real route where the problem occurred. Please treat the analysis as a
starting point rather than a conclusion.

Summary

When an inbound uses flow: xtls-rprx-vision and the destination server closes the
connection first, sing-box delivers one extra TLS record to the client — a 19-byte
record appended after the one the destination server sent.

The payload itself is intact; only the trailing record is added. Tolerant clients
ignore it, but a client that reads the stream to the end sees an unexpected record
after close_notify and aborts the connection. In my case this made one HTTP client
fail with socket hang up on every request through the tunnel, while curl — which
stops reading right after the body — worked fine on the same route.

Xray-core with the same flow does not exhibit this.

Affected

Reproduced on 1.10.0, 1.11.0, 1.12.0, 1.13.0, 1.13.16 — not a regression.
Reference: Xray-core 26.3.27 with xtls-rprx-vision is clean.

Reproduction

Everything runs on loopback; no external network is involved.

1. Certificate

openssl req -x509 -newkey rsa:2048 -keyout srv.key -out srv.crt -days 2 -nodes \
  -subj "/CN=local.test" -addext "subjectAltName=DNS:local.test"

2. sing-box server (server.json)

{
  "inbounds": [
    {
      "type": "vless",
      "listen": "127.0.0.1",
      "listen_port": 9443,
      "users": [
        {
          "uuid": "564d7377-652f-476d-b856-5bb45da37315",
          "flow": "xtls-rprx-vision"
        }
      ],
      "tls": {
        "enabled": true,
        "server_name": "local.test",
        "certificate_path": "srv.crt",
        "key_path": "srv.key"
      }
    }
  ],
  "outbounds": [
    {
      "type": "direct"
    }
  ]
}

3. sing-box client (client.json)

{
  "inbounds": [
    {
      "type": "http",
      "listen": "127.0.0.1",
      "listen_port": 3140
    }
  ],
  "outbounds": [
    {
      "type": "vless",
      "server": "127.0.0.1",
      "server_port": 9443,
      "uuid": "564d7377-652f-476d-b856-5bb45da37315",
      "flow": "xtls-rprx-vision",
      "tls": {
        "enabled": true,
        "server_name": "local.test",
        "insecure": true
      }
    }
  ]
}

4. Origin and probe (repro.go, standard library only)

The origin answers with a chunked body and closes the connection itself — that is
the trigger. The probe prints the TLS records (type:length) it receives.

// Minimal reproduction for the sing-box Vision trailing-record bug.
//
//	go run repro.go serve                  local TLS origin on 127.0.0.1:9500
//	go run repro.go probe                  direct (baseline)
//	go run repro.go probe 127.0.0.1:3140   through the tunnel
//
// The probe prints the TLS records it receives as type:length. Going through the
// tunnel must not change the sequence.
package main

import (
	"crypto/tls"
	"encoding/binary"
	"fmt"
	"io"
	"net"
	"os"
	"strings"
	"time"
)

const (
	originAddr = "127.0.0.1:9500"
	serverName = "local.test"
)

func main() {
	if len(os.Args) < 2 {
		fmt.Println("usage: repro serve | repro probe [proxy_host:port]")
		os.Exit(2)
	}
	switch os.Args[1] {
	case "serve":
		serve()
	case "probe":
		via := ""
		if len(os.Args) > 2 {
			via = os.Args[2]
		}
		probe(via)
	}
}

// serve answers with a chunked body and closes the connection itself, which is
// what triggers the bug.
func serve() {
	cert, err := tls.LoadX509KeyPair("srv.crt", "srv.key")
	if err != nil {
		panic(err)
	}
	body := strings.Repeat("0", 4000)
	response := "HTTP/1.1 200 OK\r\nTransfer-Encoding: chunked\r\nConnection: close\r\n\r\n" +
		fmt.Sprintf("%x\r\n%s\r\n0\r\n\r\n", len(body), body)

	ln, err := tls.Listen("tcp", originAddr, &tls.Config{Certificates: []tls.Certificate{cert}})
	if err != nil {
		panic(err)
	}
	fmt.Println("origin on", originAddr)
	for {
		conn, err := ln.Accept()
		if err != nil {
			continue
		}
		go func() {
			defer conn.Close()
			buf := make([]byte, 4096)
			if _, err := conn.Read(buf); err != nil {
				return
			}
			io.WriteString(conn, response)
		}()
	}
}

// recorder wraps a net.Conn and notes the TLS records passing through it.
type recorder struct {
	net.Conn
	buf     []byte
	records []string
}

func (r *recorder) Read(p []byte) (int, error) {
	n, err := r.Conn.Read(p)
	if n > 0 {
		r.scan(p[:n])
	}
	return n, err
}

func (r *recorder) scan(b []byte) {
	r.buf = append(r.buf, b...)
	for len(r.buf) >= 5 {
		length := int(binary.BigEndian.Uint16(r.buf[3:5]))
		if len(r.buf) < 5+length {
			return
		}
		r.records = append(r.records, fmt.Sprintf("%d:%d", r.buf[0], length))
		r.buf = r.buf[5+length:]
	}
}

func probe(via string) {
	raw, err := dial(via)
	if err != nil {
		fmt.Println("dial:", err)
		os.Exit(2)
	}
	defer raw.Close()

	rec := &recorder{Conn: raw}
	conn := tls.Client(rec, &tls.Config{ServerName: serverName, InsecureSkipVerify: true})
	if err := conn.Handshake(); err != nil {
		fmt.Println("handshake:", err)
		os.Exit(2)
	}
	fmt.Fprintf(conn, "GET / HTTP/1.1\r\nHost: %s\r\nConnection: close\r\n\r\n", serverName)
	io.Copy(io.Discard, conn)

	// crypto/tls stops reading the socket once it sees close_notify, so anything
	// arriving after it would go unnoticed. Drain the raw connection directly.
	raw.SetReadDeadline(time.Now().Add(500 * time.Millisecond))
	drain := make([]byte, 4096)
	for {
		n, err := raw.Read(drain)
		if n > 0 {
			rec.scan(drain[:n])
		}
		if err != nil {
			break
		}
	}

	label := via
	if label == "" {
		label = "direct"
	}
	fmt.Printf("%-16s records: %s\n", label, strings.Join(rec.records, " "))
}

// dial connects to the origin, optionally through an HTTP proxy.
func dial(via string) (net.Conn, error) {
	if via == "" {
		return net.Dial("tcp", originAddr)
	}
	conn, err := net.Dial("tcp", via)
	if err != nil {
		return nil, err
	}
	fmt.Fprintf(conn, "CONNECT %s HTTP/1.1\r\nHost: %s\r\n\r\n", originAddr, originAddr)
	header := make([]byte, 0, 256)
	one := make([]byte, 1)
	for !strings.HasSuffix(string(header), "\r\n\r\n") {
		if _, err := conn.Read(one); err != nil {
			return nil, err
		}
		header = append(header, one[0])
	}
	if !strings.Contains(string(header), " 200 ") {
		return nil, fmt.Errorf("proxy refused: %s", strings.SplitN(string(header), "\r\n", 2)[0])
	}
	return conn, nil
}

5. Run

go run repro.go serve &
sing-box run -c server.json &
sing-box run -c client.json &

go run repro.go probe                  # baseline
go run repro.go probe 127.0.0.1:3140   # through the tunnel

Result

direct           records: 22:1210 20:1 23:27 23:836 23:281 23:53 23:1203 23:2389 23:537 23:19
127.0.0.1:3140   records: 22:1210 20:1 23:27 23:836 23:281 23:53 23:1203 23:2389 23:537 23:19 23:19

Expected: the record sequence through the tunnel matches the direct one.
Actual: one extra 19-byte record at the end.

Two checks on what that record is:

• Changing the origin to abort the socket instead of shutting the TLS session down
  cleanly removes the trailing 23:19 from the direct baseline as well — so a
  19-byte trailing record here is a close_notify (2-byte alert + 1-byte inner
  content type + 16-byte AEAD tag).
• The extra one appears only when the destination server closes first. With
  Content-Length + keep-alive, where the client closes, both sequences match.

Which side

Cross-testing client and server implementations shows the server decides:

client → server	extra record
sing-box → sing-box	yes
Xray-core → sing-box	yes
sing-box → Xray-core	no
Xray-core → Xray-core	no

Cause

After the splice both peers read and write the raw socket
(vless/vision.go, directRead / directWrite paths).

VisionConn has no Close() of its own, so closing it closes the embedded TLS
connection, which writes its own close_notify onto that same socket. The peer,
already reading raw bytes, cannot distinguish it from the inner stream and passes
it on to the application.

Patch

Against sing-vmess (tested on 3aed155, the revision referenced by sing-box 1.13.16):

diff --git a/vless/vision.go b/vless/vision.go
index 2a8bc51..0949050 100644
--- a/vless/vision.go
+++ b/vless/vision.go
@@ -380,6 +380,19 @@ func (c *VisionConn) unPadding(buffer []byte) []*buf.Buffer {
 	return buffers
 }
 
+// Close closes the connection.
+//
+// After the splice both peers exchange raw TLS records over the underlying
+// socket. Closing the embedded TLS connection here writes its close_notify onto
+// that same socket, where the peer -- already reading raw -- forwards it to the
+// application as trailing garbage. Once spliced, close the raw connection.
+func (c *VisionConn) Close() error {
+	if c.directRead || c.directWrite {
+		return c.netConn.Close()
+	}
+	return c.Conn.Close()
+}
+
 func (c *VisionConn) NeedAdditionalReadDeadline() bool {
 	return true
 }

With this applied, the tunnel output matches the direct baseline, and the HTTP
client that used to fail now works over the same route.

Verified against the reproduction above and against my own production
route (VLESS + Vision + reality over TCP).

Logs

Supporter

• I am a sponsor

Integrity requirements

• I confirm that I have read the documentation, understand the meaning of all the configuration items I wrote, and did not pile up seemingly useful options or default values.
• I confirm that I have provided the server and client configuration files and process that can be reproduced locally, instead of a complicated client configuration file that has been stripped of sensitive data.
• I confirm that I have provided the simplest configuration that can be used to reproduce the error I reported, instead of depending on remote servers, TUN, graphical interface clients, or other closed-source software.
• I confirm that I have provided the complete configuration files and logs, rather than just providing parts I think are useful out of confidence in my own intelligence.

Start in vless/vision.go, especially the VisionConn directRead and directWrite paths, and review the provided repro.go setup. Run the direct and tunneled probes to confirm the extra trailing 23:19 record. Done means the tunneled record sequence matches the direct baseline and the HTTP client succeeds through VLESS Vision.