WireGuard outbound does not recover after a transient network outage (stale UDP socket; endpoint never re-resolved)

[almatv54]

Integrity requirements

• I have read all the comments in the issue template and ensured that this issue meet the 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 provided the complete config and logs, rather than just providing the truncated parts based on my own judgment.
• I searched issues and did not find any similar issues.
• The problem can be successfully reproduced in the latest Release

Description

A WireGuard outbound whose peer endpoint is given as a domain name stops working after a short loss of upstream network connectivity on the host, and never recovers on its own — only restarting the Xray process brings it back.

Scenario: the host had a brief network interruption (the machine stayed up, power was fine, only the uplink was gone for several minutes). After connectivity was restored, Xray itself was clearly still running and healthy — other inbounds kept accepting connections and responding normally —but everything routed through the WireGuard outbound stayed dead indefinitely.

Reading the source, two things in proxy/wireguard seem to combine to prevent recovery:

1. Re-dial only triggers on a read error. In bind.go, netBindClient.Send only re-dials when endpoint.conn == nil, and conn is reset to nil only inside the receive goroutine when ReadFrom returns an error (connectTo). On a write error, Send returns the error but does not reset endpoint.conn, so no re-dial happens. A connected UDP socket typically does not produce a read error when the peer silently disappears during an outage (no ICMP), so the receive goroutine just blocks, conn stays non-nil, writes keep going into a dead socket, and the outbound never re-establishes.

2. The endpoint is resolved once and cached. createIPCRequest in client.go resolves the endpoint domain to an IP a single time and never re-resolves it for the lifetime of the device, so even a re-dial would reuse a possibly-stale address.

Suggested directions: on a write error in Send, also reset/close endpoint.conn so the next Send re-dials; and retain the endpoint domain to re-resolve it on re-dial.

Reproduction Method

1. Start Xray with the config below (a local SOCKS inbound routed to a WireGuard outbound whose peer endpoint is a domain name).
2. Confirm traffic works: curl -x socks5h://127.0.0.1:1080 https://api.ipify.org.
3. Cut the host's network for ~3-5 minutes (e.g. drop all egress with the firewall, or bring the uplink down), then restore it.
4. Run the same curl again. It hangs/fails and never recovers; only restarting Xray restores the WireGuard outbound.

Client config

Details

No separate Xray client is needed to reproduce. Traffic is generated against the local SOCKS inbound of the single instance below, e.g.:
curl -x socks5h://127.0.0.1:1080 https://api.ipify.org

Server config

Details

{
  "log": {
    "loglevel": "debug",
    "dnsLog": true
  },
  "inbounds": [
    {
      "tag": "socks-in",
      "protocol": "socks",
      "listen": "127.0.0.1",
      "port": 1080,
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "wireguard",
      "tag": "wg-out",
      "settings": {
        "secretKey": "SECRETKEY",
        "address": [
          "10.0.0.2/32"
        ],
        "peers": [
          {
            "publicKey": "PUBLICKEY",
            "endpoint": "wg.example.com:51820",
            "allowedIPs": [
              "0.0.0.0/0",
              "::/0"
            ]
          }
        ],
        "domainStrategy": "ForceIPv4"
      }
    }
  ],
  "routing": {
    "rules": [
      {
        "inboundTag": [
          "socks-in"
        ],
        "outboundTag": "wg-out"
      }
    ]
  }
}

Client log

Details

Not applicable — reproduction uses only the local SOCKS inbound of the single instance above; there is no separate Xray client.

Server log

Details

Debug logs were not retained from the original incident.

[LjhAUMEM]

还发现个问题，客户端多 peer 下每个 peer 都会持有一个 socket，但实际应该一个 tun 设备持有一个 socket，准备重写下 bind，话说 outboud 在 init 阶段为什么拿不到 streamsettings...

另外 wg 似乎理论上也是支持端口跳跃，还没测试 (off-topic)

[almatv54]

Thanks for digging into this — nice catch on the per-peer vs. per-device socket model; consolidating to one socket per tun device does sound like the cleaner design.

One note so the recovery case doesn't get lost while you're in there: in my setup each WireGuard outbound has a single peer with a domain endpoint, so the multi-peer socket consolidation isn't strictly what bit me. But the code you're about to rewrite (bind / Send / connectTo) is exactly where the "no recovery after a brief upstream outage" behavior lives, so the two seem worth covering in the same pass:

• Send only re-dials when conn == nil, and conn is reset only on a read error in the receive goroutine. A connected UDP socket usually won't surface a read error when the upstream silently goes away during an outage, so conn stays non-nil, writes keep going into a dead socket, and the outbound never re-establishes on its own — only a restart brings it back. Resetting/closing conn on a write error in Send would let the next Send re-dial.
• The endpoint domain is resolved once at device build (createIPCRequest) and cached, so even a re-dial would reuse a possibly-stale IP. Keeping the domain around to re-resolve on re-dial would cover the case where the address changed during the outage.

[LjhAUMEM]

@almatv54 try this https://github.com/XTLS/Xray-core/actions/runs/27116764302

[almatv54]

@LjhAUMEM, thanks for the quick turnaround on this — the rewrite looks like the right call.

From reading the PR: moving to a single persistent PacketConn per device with WriteTo (instead of a connected per-endpoint socket whose conn only got reset on a read error) structurally removes the case that bit me. An unconnected UDP socket doesn't go stale across a brief uplink loss, so once connectivity is back WireGuard's own handshake retries should bring the tunnel up on their own — no restart needed. That was exactly the failure mode here.

One small note for completeness: the endpoint domain still seems to be resolved once in ParseEndpoint and cached for the device's lifetime, so an endpoint whose IP changes mid-outage wouldn't be picked up without a re-resolve. Not relevant to my case (the host stayed up, only the uplink blipped, so the IP was unchanged) — just flagging it in case it's worth a follow-up.

Looks good to me overall.

[LjhAUMEM]

其实 peer endpoint 里本就不该是域名，你如果找其他实现也都只是在程序启动时给你解析一次，refer to peer Endpoint https://github.com/WireGuard/wireguard-go/blob/ecfc5a8d54462e18e13c72173e2623d16d8e25a0/conn/conn.go#L74-L85

[almatv54]

其实 peer endpoint 里本就不该是域名，你如果找其他实现也都只是在程序启动时给你解析一次，refer to peer Endpoint https://github.com/WireGuard/wireguard-go/blob/ecfc5a8d54462e18e13c72173e2623d16d8e25a0/conn/conn.go#L74-L85

Makes sense — thanks for the explanation. Agreed that one-time resolution matches how upstream and other implementations behave, so the endpoint-domain part is fine as-is.

Appreciate the quick turnaround on this.