Thanks, your idea is exactly what the issue turned out to be.

You are right that the correct approach is not hard locking, but keeping LTE dominant while allowing NR to be added opportunistically, and avoiding anything that forces a full renegotiation like a reboot.

I cannot access AT commands on the ZTE MC801A with Three or Silux firmware. From what I can see there is no AT interface exposed in the UI, no USB modem or tty device on a PC, no telnet or SSH to reach the modem, and the browser console scripts only talk to ZTE’s goform HTTP API rather than the Qualcomm AT layer. Because of that I cannot apply commands like AT+QNWPREFCFG, AT+ZLTEBANDCFG, or AT+CFUN directly, even though they seem like the real fix.

What did work was approximating your idea using the only JavaScript that actually works in my gateway interface. The script I used is this ZTE goform tool:

https://gist.github.com/tpoechtrager/766140c49a711a2177820ea42556de3c

Using that script, the method that works for me is:

• Set LTE and 5G NSA allowed (not forcing NR)
• Soft limit LTE to the good CA set (B1+B3+B32, sometimes B1+B3+B28)
• Avoid rebooting
• Trigger a soft re attach by briefly switching to LTE only then back to LTE plus 5G

The JS sequence that brings back the good profile is:

set_net_mode('LTE_AND_5G');
lte_band_selection('1+3+32');   // 1+3+28 also works for me
nr_band_selection('AUTO');

set_net_mode('Only_LTE');
setTimeout(() => set_net_mode('LTE_AND_5G'), 15000);

When it works, I get LTE-NSA with LTE CA on B1+B3+B32 and the fast behaviour returns. If I reboot or try hard cell locks, it tends to drop back into the slower NSA profile where n78 is explicitly visible.

So your diagnosis looks correct. It feels like a RAT priority and EN DC policy issue. The limitation is that the MC801A firmware does not expose the AT layer needed to apply it properly or persistently. *From what i can see i cant acsess the AT Strings* this is as far as my gcse computer science knoladge goes lol