Summary
WireGuard/AmneziaWG handshakes fail against a server running AmneziaWG v1.5 (v3.1+) with RandomTrailers enabled, because FlClash's outbound wrapper never forwards a random-trailers option into the UAPI config, even though the pinned core already supports it.
Details
- FlClash version tested: v0.8.97
- Core:
chen08209/Clash.Meta@70f0570, pinning github.com/metacubex/amneziawg-go v0.0.0-20260816073447-736a78668832
- Server: AmneziaWG 1.5,
RandomTrailers = on
That pinned amneziawg-go does implement random_trailers in its UAPI (device/uapi.go:530), but adapter/outbound/wireguard.go in both the pinned commit and the current FlClash branch HEAD never writes random_trailers= into the UAPI config — there's no RandomTrailers field on the WireGuard outbound option struct at all.
Effect: with trailers on, the server appends fastrandn(udpWindow - packetSize) random bytes to every handshake response (device/send.go, sendHandshakeResponse). The client-side engine's DeterminePacketTypeAndPadding (device/receive.go ~line 604) only accepts a handshake response when size == padding+MessageSize, since randomTrailers is never set to true on the client. So every handshake response from a RandomTrailers-enabled server gets silently dropped as malformed, even though the initial handshake (client → server) succeeds and the server correctly learns the peer.
Symptom from the server side: peer's endpoint gets learned, sent/received byte counters climb, but latest handshake never appears — because the client never accepts the response and never sends a data packet under the new keypair.
Upstream fix already exists
MetaCubeX/mihomo@Alpha already has this: adapter/outbound/wireguard.go:139
```go
RandomTrailers bool proxy:"random-trailers,omitempty" // AmneziaWG v3.1+
```
emitted as random_trailers=1 in the UAPI config it builds.
Ask
Please sync FlClash's Clash.Meta core (or just this option) with MetaCubeX/mihomo@Alpha's WireGuard outbound, so amnezia-wg-option.random-trailers: true in a proxy profile actually reaches the engine.
Summary
WireGuard/AmneziaWG handshakes fail against a server running AmneziaWG v1.5 (v3.1+) with
RandomTrailersenabled, because FlClash's outbound wrapper never forwards arandom-trailersoption into the UAPI config, even though the pinned core already supports it.Details
chen08209/Clash.Meta@70f0570, pinninggithub.com/metacubex/amneziawg-go v0.0.0-20260816073447-736a78668832RandomTrailers = onThat pinned
amneziawg-godoes implementrandom_trailersin its UAPI (device/uapi.go:530), butadapter/outbound/wireguard.goin both the pinned commit and the currentFlClashbranch HEAD never writesrandom_trailers=into the UAPI config — there's noRandomTrailersfield on the WireGuard outbound option struct at all.Effect: with trailers on, the server appends
fastrandn(udpWindow - packetSize)random bytes to every handshake response (device/send.go,sendHandshakeResponse). The client-side engine'sDeterminePacketTypeAndPadding(device/receive.go~line 604) only accepts a handshake response whensize == padding+MessageSize, sincerandomTrailersis never set totrueon the client. So every handshake response from aRandomTrailers-enabled server gets silently dropped as malformed, even though the initial handshake (client → server) succeeds and the server correctly learns the peer.Symptom from the server side: peer's endpoint gets learned,
sent/receivedbyte counters climb, butlatest handshakenever appears — because the client never accepts the response and never sends a data packet under the new keypair.Upstream fix already exists
MetaCubeX/mihomo@Alphaalready has this:adapter/outbound/wireguard.go:139```go
RandomTrailers bool
proxy:"random-trailers,omitempty"// AmneziaWG v3.1+```
emitted as
random_trailers=1in the UAPI config it builds.Ask
Please sync FlClash's
Clash.Metacore (or just this option) withMetaCubeX/mihomo@Alpha's WireGuard outbound, soamnezia-wg-option.random-trailers: truein a proxy profile actually reaches the engine.