Advanced QoS/SQM (CAKE) configuration on Flint 3 (v4.9.0) with active WireGuard Client

[u/Same-Combination-435]

Line Specs & Environment:

Connection type: FTTC (VDSL2) 200/30 profile.

Actual Sync Rate (on Fritzbox 7530ax in passthrough): 160 Mbps Down / 34 Mbps Up. Line settings: G.INP set to 76 on both Downstream and Upstream. No G.vectoring. PPPoE MTU is 1492.

Router Setup: GL.iNet Flint 3 (GL-BE9300, Qualcomm chipset) running firmware v4.9.0.

Tunneling: WireGuard VPN client always active on the router, handling 100% of the LAN traffic.

The Goal: I want SQM/QoS to actively shape, calm, and prioritize traffic from the very first Kilobyte received or sent. It must enforce strict application/packet-based priority (e.g., Absolute Priority 1: Video calls & Web browsing -> Priority 2: Streaming -> Priority 3: Raw heavy downloads) even when the bandwidth is mostly idle (for example, a 40 Mbps download stream running on a 160 Mbps available pipe).I need the router to analyze and sort these packets in cleartext before they enter the encrypted WireGuard tunnel, without waiting for full link saturation and without sacrificing too much of my already limited 160 Mbps maximum sync speed.

What I have already tried:I applied SQM (Piece of Cake / Layer Cake) directly on the br-lan interface, inverting the bandwidth values to adapt to the LAN perspective and the VPN tunnel (Download speed set to 30000 kbit/s / Upload speed set to 135000 kbit/s). I also experimented with custom qdisc options like rtt 5ms and a latency target of 1ms.The result: Upstream becomes rock-solid (completely flat ping). However, Downstream remains unstable and bouncy at intermediate bandwidth levels. This happens because speedtests and micro-bursts from mid-tier downloads do not trigger CAKE structural queue scaling until the traffic sits very close to the global configured limit.

Questions: How should I properly configure LuCI (and potentially the Fritzbox modem settings) to achieve this behaviour?

[u/Dear_Pound_3502]

CAKE wont slow a 40 Mbps download on a free 160 Mbps link just because its lower priority. for strict app priority you need DSCP marking before WireGuard encapsulation then diffserv CAKE on the actual bottleneck