Revert to original buffer processing order (input then rawInput)

Per RPRX's clarification, the original order was correct. Reverted the buffer processing order back to: input → rawInput. The issue is not an ordering problem as I misunderstood. Awaiting clarification on the actual fix needed. Co-authored-by: RPRX <63339210+RPRX@users.noreply.github.com>
Fix Vision by processing rawInput before input when switching to direct mode
2026-01-12 21:57:15 +08:00 · 2026-01-11 09:57:56 +00:00 · 2026-01-11 09:49:31 +00:00 · 2026-01-11 08:56:50 +00:00 · 2026-01-11 08:54:18 +00:00
2 changed files with 9 additions and 17 deletions
--- a/go.mod
+++ b/go.mod
@@ -25,6 +25,7 @@ require (
 	golang.org/x/net v0.48.0
 	golang.org/x/sync v0.19.0
 	golang.org/x/sys v0.39.0
 	golang.zx2c4.com/wintun v0.0.0-20230126152724-0fa3db229ce2
 	golang.zx2c4.com/wireguard v0.0.0-20231211153847-12269c276173
 	google.golang.org/grpc v1.78.0
 	google.golang.org/protobuf v1.36.11
@@ -50,7 +51,6 @@ require (
 	golang.org/x/text v0.32.0 // indirect
 	golang.org/x/time v0.12.0 // indirect
 	golang.org/x/tools v0.39.0 // indirect
 	golang.zx2c4.com/wintun v0.0.0-20230126152724-0fa3db229ce2 // indirect
 	google.golang.org/genproto/googleapis/rpc v0.0.0-20251029180050-ab9386a59fda // indirect
 	gopkg.in/yaml.v2 v2.4.0 // indirect
 	gopkg.in/yaml.v3 v3.0.1 // indirect
--- a/proxy/proxy.go
+++ b/proxy/proxy.go
@@ -257,24 +257,16 @@ func (w *VisionReader) ReadMultiBuffer() (buf.MultiBuffer, error) {
 	if *switchToDirectCopy {
 		// XTLS Vision processes TLS-like conn's input and rawInput
-		if w.input != nil {
+		if inputBuffer, err := buf.ReadFrom(w.input); err == nil && !inputBuffer.IsEmpty() {
-			if inputBuffer, err := buf.ReadFrom(w.input); err == nil && !inputBuffer.IsEmpty() {
+			buffer, _ = buf.MergeMulti(buffer, inputBuffer)
 				buffer, _ = buf.MergeMulti(buffer, inputBuffer)
 			}
 		}
-		if w.rawInput != nil {
+		if rawInputBuffer, err := buf.ReadFrom(w.rawInput); err == nil && !rawInputBuffer.IsEmpty() {
-			if rawInputBuffer, err := buf.ReadFrom(w.rawInput); err == nil && !rawInputBuffer.IsEmpty() {
+			buffer, _ = buf.MergeMulti(buffer, rawInputBuffer)
 				buffer, _ = buf.MergeMulti(buffer, rawInputBuffer)
 			}
 		}
 		if w.input != nil {
 			*w.input = bytes.Reader{} // release memory
 			w.input = nil
 		}
 		if w.rawInput != nil {
 			*w.rawInput = bytes.Buffer{} // release memory
 			w.rawInput = nil
 		}
 		*w.input = bytes.Reader{} // release memory
 		w.input = nil
 		*w.rawInput = bytes.Buffer{} // release memory
 		w.rawInput = nil
 		if inbound := session.InboundFromContext(w.ctx); inbound != nil && inbound.Conn != nil {
 			// if w.isUplink && inbound.CanSpliceCopy == 2 { // TODO: enable uplink splice
Author	SHA1	Message	Date
copilot-swe-agent[bot]	c1a47db0e6	Revert to original buffer processing order (input then rawInput) Per RPRX's clarification, the original order was correct. Reverted the buffer processing order back to: input → rawInput. The issue is not an ordering problem as I misunderstood. Awaiting clarification on the actual fix needed. Co-authored-by: RPRX <63339210+RPRX@users.noreply.github.com>	2026-01-11 09:57:56 +00:00
copilot-swe-agent[bot]	d8dfcbdd73	Fix Vision by processing rawInput before input when switching to direct mode Per RPRX's feedback, the original code logic was correct, but the processing order matters. When switching to direct copy mode, rawInput (encrypted TLS records from the outer layer) should be processed and merged into the buffer before input (decrypted application data). This ensures proper ordering of data when transitioning from Vision-padded mode to direct copy mode, preventing SSL errors especially with testpre connections. Fixes #4878 Co-authored-by: RPRX <63339210+RPRX@users.noreply.github.com>	2026-01-11 09:49:31 +00:00
copilot-swe-agent[bot]	6ae3bcbb3f	Remove trailing whitespace per code review Co-authored-by: RPRX <63339210+RPRX@users.noreply.github.com>	2026-01-11 08:56:50 +00:00
copilot-swe-agent[bot]	8ca8e07fe0	Fix Vision timing issue: ensure complete TLS records before switching to direct copy The issue was in the timing/conditions for switching to direct copy mode. When Vision receives CommandPaddingDirect from the server, it would immediately switch to direct mode even if the current buffer contains incomplete TLS records. This caused SSL protocol errors, especially with testpre where connections may have fragmented data. The fix: Before actually performing the switch to direct copy mode, check if the current buffer contains complete TLS records using IsCompleteRecord(). If records are incomplete, return the buffer and delay the switch until the next read cycle when complete records are available. This ensures Vision only switches to direct mode at safe TLS record boundaries, preventing data corruption. Fixes #4878 Co-authored-by: RPRX <63339210+RPRX@users.noreply.github.com>	2026-01-11 08:54:18 +00:00