Skip to content

Conversation

Copy link
Contributor

Copilot AI commented Jan 16, 2026

When multiple WireGuard peers are configured in an outbound, only the first established peer works. Subsequent peer connections fail with "Received invalid response message" because responses are incorrectly associated with the wrong endpoint.

Root Cause

All peer connections shared a single readQueue channel. Each peer's connectTo() spawned a goroutine reading from this shared queue, causing race conditions where responses from peer B could be attributed to peer A's endpoint.

Changes

  • Architecture: Changed from pull-based (receiver requests buffer, sender fills) to push-based (sender pushes data with endpoint identity)

    • Each endpoint's goroutine now reads from its own connection and pushes {data, endpoint} tuples to shared responseRecv channel
    • ReceiveFunc simply receives from this channel with correct endpoint association
  • Memory: Added sync.Pool for buffer reuse to reduce GC pressure

// Before: goroutines compete for read requests, wrong endpoint association
v, ok := <-readQueue      // any goroutine grabs this
i, err := c.Read(v.buff)  // reads from THIS goroutine's connection
v.endpoint = endpoint     // but endpoint might not match the data source

// After: each goroutine owns its connection, pushes with correct identity
buff := bufferPool.Get().([]byte)
i, err := c.Read(buff)
responseRecv <- &netReadInfo{buff: buff, bytes: i, endpoint: endpoint, err: err}
Original prompt

深刻理解 Xray-core 和依赖库的代码以及 #4507 所述的问题,自己找出真正的问题所在并修复它


💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

@RPRX
Copy link
Member

RPRX commented Jan 16, 2026

#5510 (comment)

@RPRX
Copy link
Member

RPRX commented Jan 16, 2026

@Fangliding 3.5 sonnet 和 4.5 opus 都说是 readQueue 的问题,可能还真的是

@Fangliding
Copy link
Member

确实是这个问题

Copilot AI and others added 2 commits January 16, 2026 16:19
In the original implementation, all peer connections shared a single
readQueue channel where ReceiveFunc workers would request buffers.
This caused responses from different peers to be incorrectly associated
with the wrong endpoint when multiple peers were active.

The fix changes to a push-based architecture where:
- Each endpoint's read goroutine pushes responses directly to a shared
  responseRecv channel along with the correct endpoint identity
- The ReceiveFunc workers simply receive from this channel
- This ensures each response is correctly associated with its source endpoint

Fixes issue #4507: multi wg peers outbound only one established

Co-authored-by: RPRX <63339210+RPRX@users.noreply.github.com>
Co-authored-by: RPRX <63339210+RPRX@users.noreply.github.com>
@RPRX
Copy link
Member

RPRX commented Jan 16, 2026

@Fangliding 那你看一下它代码写得有没有问题吧

@Fangliding
Copy link
Member

Fangliding commented Jan 16, 2026

这个应该不太对 我也不知道我想的是不是对的 不过主要是复现这个确实有点麻烦 而且还是那句话 用的人少 连个测试的都找不到

Copilot AI changed the title [WIP] Fix underlying issue in Xray-core as per issue #4507 Fix WireGuard multi-peer outbound: responses routed to wrong endpoint Jan 16, 2026
Copilot AI requested a review from RPRX January 16, 2026 16:25
@RPRX
Copy link
Member

RPRX commented Jan 16, 2026

@Fangliding 本地弄个 WireGuard 测一下吧

Changed from pull-based (receiver requests buffer, sender fills) to push-based (sender pushes data with endpoint identity)

光看描述感觉挺对的

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants