I recently replaced my hAP ax3 with a hAP be3, and these are my first impressions after setting it up and moving my network over.

I'm still learning some of the changes introduced with Wi-Fi 7 and MLO/MLD, so some of the points below are observations and questions rather than definitive conclusions. I'd be interested in hearing how others are configuring theirs.

MLD / Wi-Fi 7

The first major change for me is MLD (Multi-Link Device).

It appears to work as I expected with my Wi-Fi 7 clients, but I need to adapt to a very different way of thinking about Wi-Fi compared with how I managed my hAP ax3.

Previously, I had separate SSIDs for 2.4 GHz and 5 GHz. For example, I could explicitly identify a device as being on 2.4 GHz and apply different QoS rules or expectations based on that. Devices on 5 GHz generally had significantly higher expected throughput.

With MLD, my understanding is that, for the intended multi-link operation, the participating bands need to be configured consistently, particularly using the same SSID and WPA3 configuration across the 2.4, 5, and 6 GHz radios. And its a must that needs to be WPA3

That changes things quite a bit from the way I previously managed my network.

For example, I used to have explicit QoS policies for certain devices depending on whether they were connected to 2.4 or 5 GHz. With MLD, I'm not yet sure what the best approach is when a client can potentially use multiple links/bands.

I also have a question about band steering.

If MLD allows a Wi-Fi 7 client to use multiple bands simultaneously, does traditional band steering become largely irrelevant for those clients? Or does MikroTik still use steering mechanisms to determine which links/bands should be used?

My understanding may be incomplete here, so I'd appreciate clarification from people who have been working with MLO/MLD more extensively.

The default Wi-Fi configuration surprised me

Something else that caught my attention is how the hAP be3 presents the wireless interfaces by default.

In the WiFi configuration I see four entries:

• MLD1
• wifi1
• wifi2
• wifi3

I initially expected the three radios to be configured with something close to the best capabilities available for their respective bands.

However, the defaults are interesting.

For example:

MLD1

• WPA3-PSK only

2.4 GHz (wifi1)

• 20 MHz channel width
• 802.11G band
• WPA3-PSK
• WPA2-PSK

5 GHz (wifi2)

• BE
• 20/40/80 MHz
• WPA3-PSK
• WPA2-PSK

6 GHz (wifi3)

• BE
• 20/40/80/160/320 MHz
• WPA3-PSK only

The 2.4 GHz configuration in particular surprised me. Why is it explicitly configured as 802.11G rather than N, AX, or BE?

What's even more interesting is that when I look at the registration table, I can see older devices connected to wifi1. Some show G, while others show N, despite the interface apparently being configured for G.

So I'm trying to understand exactly what MikroTik is doing here.

Is the band=2ghz-g default intentional for compatibility reasons? Would it be recommended to change this to AX/BE, or is there a good reason to leave the default configuration alone?

I'd be interested to hear what others are doing with the 2.4 GHz radio.

Check the country setting!

Another thing I noticed, which I think is particularly important for people who are new to MikroTik:

The default country/regulatory setting appears to be Latvia, even though it is not particularly obvious in the configuration that a specific country has been explicitly selected.

This is important because the country setting has a significant impact on the maximum permitted TX power and available channels for each wireless band.

If you set up the hAP be3 and leave the default configuration as it is, you may notice significantly lower transmit power and wireless range compared with what you were getting from your previous router. It can easily give the impression that the hAP be3 has weaker radios.

So one of the first things I would recommend doing is checking the country setting and selecting the actual country where you are operating the device.

Once the correct country is selected, MikroTik will apply the corresponding regulatory limits for each band, which can make a very noticeable difference in the maximum allowed TX power and channel availability, depending on your country.

This is especially worth mentioning for less experienced MikroTik users, because someone could easily leave the default Latvia setting in place and assume that the wireless power they are seeing is simply what the hAP be3 is capable of.

Containers / USB storage

On my hAP ax3 I had AdGuard Home running in a container using the router's internal storage, so I had not really paid much attention to the newer MikroTik App functionality.

With the hAP be3, I understand that the App functionality requires external storage, meaning that I would need a USB device connected to the router 24/7.

This raises a question for me:

What type of USB storage would you recommend for permanent 24/7 use on a MikroTik router?

I'm asking because I remember using USB storage with MikroTik/MetaROUTER and other applications more than 10 years ago, and heavy read/write activity could eventually destroy cheap USB flash drives.

So I'm reluctant to just plug in a random inexpensive USB stick and leave it running permanently.

Would a high-endurance USB flash drive be appropriate? An external SSD? Something else?

It's also a little disappointing that there isn't an NVMe/M.2 connector for storage. I think that would have been a much more interesting solution for this kind of workload.

If anyone is running containers or MikroTik Apps from USB storage 24/7, I'd really appreciate recommendations on what type of device to use.

Thermals

https://preview.redd.it/1q71b8ehedkh1.jpg?width=4096&format=pjpg&auto=webp&s=821006e3b5c2bdda7ee21f57cb816ccdd7181956

Finally, something that immediately caught my attention physically:

The hAP be3 gets noticeably hotter than my hAP ax3.

The heatsink appears to be integrated around the MikroTik logo area, and that entire section of the router gets quite warm to the touch compared with the ax3.

At first I thought perhaps the hAP be3 was simply consuming significantly more power.

However, after configuring it similarly to how I had my hAP ax3 configured, I'm seeing roughly 7–8 W of power consumption, which is actually very similar to what I was getting from the ax3.

https://preview.redd.it/bzakd1ztedkh1.jpg?width=939&format=pjpg&auto=webp&s=04880413a3a7f734e48df3f51218814bd8fd6331

So the higher surface temperature doesn't appear to be explained simply by significantly higher power consumption.

I'm curious whether this is just a consequence of how the hAP be3 transfers heat from its SoC/radios to the enclosure, or whether there is something else going on thermally.

Overall

So far, I'm happy with the hAP be3. The move to Wi-Fi 7/MLD is probably the biggest change for me, not necessarily because it is difficult to configure, but because it changes some of the assumptions I previously made when managing my wireless network.

I'm still experimenting with the best way to handle QoS, band selection, MLD, and the different radio capabilities.

I'd especially like to hear from other hAP be3 owners about:

1. How are you configuring MLD?
2. Are you using the same SSID/WPA3 configuration across all three bands?
3. Does band steering still have a meaningful role with MLD clients?
4. What are you using for the 2.4 GHz wifi1 configuration?
5. Are you running containers/MikroTik Apps from USB storage? If so, what type of USB storage?
6. How are your hAP be3 temperatures compared with the hAP ax3?

These are just my first impressions after moving from an ax3, so I'm very interested in hearing what I'm misunderstanding or what others have discovered.

I may have found a way to significantly improve Nintendo Switch download speeds, at least on some networks.

After reading several old discussions about using a local HTTP proxy, I decided to test it myself.

My setup:

• Nintendo Switch 1 and 2
• Wi-Fi connection
• MikroTik router
• PPPoE ISP connection
• Tinyproxy running inside a Debian LXC container on Proxmox

Results:

The proxy produced a noticeable improvement in download performance compared to the default configuration.

I can't guarantee this will help everyone, but it was enough of a difference that I think it's worth sharing still in 2026

Why this might work

The theory is that the Switch may not handle some TCP scenarios optimally, especially when downloading from Nintendo's CDN over higher-latency connections.

By placing a local proxy between the Switch and the Internet:

Switch -> Tinyproxy -> Internet

the Switch communicates with a device only a few milliseconds away, while the proxy maintains the remote connection.

This does NOT modify Nintendo traffic, cache games, or hack the console. It simply acts as an HTTP proxy.

How to test it

1. Create a Debian or Ubuntu machine (physical, VM, LXC, Raspberry Pi, etc.)
2. Install Tinyproxyapt update apt install tinyproxy -y
3. Edit the configurationnano /etc/tinyproxy/tinyproxy.conf

Make sure your LAN is allowed, usually its this type of IP 192.168.x.x/24 in most home scenarios, you should change to your scenario:

Port 8888

Allow 192.168.1.0/24

Adjust the subnet for your network.

1. Restart Tinyproxysystemctl restart tinyproxy
2. Verify it is listeningss -lntp | grep 8888
3. Configure the Switch

Internet Settings -> Your Network -> Change Settings -> Proxy Settings

Server:
IP_OF_TINYPROXY

Port:
8888

Authentication:
No

MTU testing

This is important.

Many guides recommend setting MTU to 1500.

However, your optimal MTU depends on your ISP and network.

In my case, I use PPPoE and my MikroTik router reports:

MTU: 1480
MRU: 1492

this result is interesting cause usually for PPPoE cases should be 1492 but in my case its 1480. Because of that, I tested values closer to my actual WAN MTU.

Suggested values to test:

1480
1492
1500
1400

Do not assume 1500 is always best.

Run the same download multiple times and compare results.

Things to verify

• Use 5 GHz Wi-Fi if possible
• Make sure signal strength is good
• Test with and without the proxy
• Compare real download times, not only Nintendo's speed test
• If using Ethernet, verify every link negotiates at 1 Gbps

What I'd like to know

If you try this, please post:

• Switch model (V1, V2, OLED)
• Wi-Fi or Ethernet
• ISP type (PPPoE, DHCP, etc.)
• Download speed before
• Download speed after
• MTU used

I'm curious to see whether this is network-specific or if it consistently improves performance across different ISPs and regions.

but with this it increases speed x3 or x4 on switch 1 and i got x2.5 on switch 2 using WiFi

------------------------------------------------------------------------------------
UPDATE: https://i.imgur.com/KjPTPHk.png

I wanted to make sure the Switch wasn't bypassing Tinyproxy, so I monitored both the proxy logs and the network throughput of the Linux container.

Install bmon:

apt update
apt install bmon -y

Run:

bmon

At the same time, follow Tinyproxy logs:

journalctl -fu tinyproxy

The screenshot below shows both views simultaneously.

On the left:

• bmon displaying real-time throughput through the proxy interface.

On the right:

• Tinyproxy logs showing the Switch connecting to Nintendo infrastructure, including hosts such as:receive-lp1.dg.srv.nintendo.net superfly.hac.lp1.d4c.nintendo.net cdn-image-*.baas.nintendo.com

This confirms that:

• The Switch is actually using Tinyproxy.
• Nintendo traffic is traversing the proxy.
• Throughput can be measured directly from the Linux host.
• Results do not rely solely on Nintendo's built-in speed test.

One thing I also noticed is that bmon reports throughput in MiB/s, not Mbps.

For example:

14 MiB/s × 8 ≈ 112 Mbps
10 MiB/s × 8 ≈ 80 Mbps

So make sure to convert units correctly when comparing results.

Before trying Tinyproxy, my Switch 1 download speeds were all over the place.

I would typically see:

10 Mbps
20 Mbps
sometimes 25 Mbps

with occasional spikes higher than that.

Downloads felt inconsistent and throughput would fluctuate constantly.

The screenshot below was taken after implementing the Tinyproxy setup and monitoring the actual traffic flowing through the proxy server.

So huge improvement as you can see for the switch 1, for switch 2 since its already "fast" but not that fast my test reflects x2.5 improvement