Using an ESP32 as a Wi-Fi bridge, relaying traffic between networks with network address translation, is a tempting trick: the chip has Wi-Fi, it runs a TCP/IP stack, and NAT code is available. It works, after a fashion. But the throughput ceiling is low, often just a few megabits per second, and builders who expect router-like performance end up confused when the bridge chokes on traffic a phone handles effortlessly. The limits are architectural, not bugs: the ESP32 was designed as an endpoint, and every packet it forwards pays taxes that endpoints never pay.
What NAT Costs Per Packet
Forwarding a packet through NAT is not free. For each packet, the ESP32 must receive it on one interface, look up or create a translation-table entry mapping the connection, rewrite the source or destination address and port, recompute the IP and TCP/UDP checksums, and transmit it on the other interface. Each of those steps consumes CPU cycles and memory bandwidth on a microcontroller running at a few hundred megahertz with limited RAM. Contrast this with the ESP32's normal role as an endpoint, where the stack handles packets addressed to itself with a simpler path. The per-packet cost means throughput scales inversely with packet rate: small packets at high rates, the worst case, saturate the CPU long before the Wi-Fi radio's theoretical bandwidth is reached. Large packets fare better per byte, but real traffic is a mix, and the small-packet tax dominates interactive use.
The Wi-Fi Half-Duplex Penalty
Wi-Fi is half-duplex: a radio cannot transmit and receive simultaneously on the same channel. An ESP32 bridge forwarding between two Wi-Fi networks typically uses one radio switching between them, or two virtual interfaces on one radio, which means every forwarded packet crosses the air twice, once inbound and once outbound, on the same channel. The effective airtime doubles, so the already-modest throughput halves again before the CPU even gets involved. This is the fundamental reason Wi-Fi-to-Wi-Fi bridging on a single radio performs poorly regardless of processor speed: the channel itself is the bottleneck. A bridge between Wi-Fi and a wired interface avoids the double-airtime penalty, but the ESP32 has no native Ethernet without extra hardware, which is why most ESP32 bridge projects are Wi-Fi to Wi-Fi and inherit the penalty.
Memory and Connection Table Limits
NAT requires remembering every active connection in a translation table, and the ESP32's RAM is small. Each table entry consumes tens of bytes; a few hundred concurrent connections, normal for a single modern device browsing the web, consume a meaningful fraction of available heap. When the table fills, new connections fail or old ones get evicted prematurely, producing the classic symptom of a bridge that works for one device doing one thing but falls apart under real browsing. Aggressive connection timeouts help, evicting idle entries quickly, but they break long-lived connections and add their own CPU cost in table management. The heap is also shared with the Wi-Fi driver's own buffers, the TCP/IP stack, and the application, so NAT table sizing is a zero-sum negotiation with everything else the chip is doing.
Where ESP32 Bridging Actually Fits
The limits define the use cases, and there are legitimate ones. Bridging a low-bandwidth IoT device onto a network, a sensor that phones home occasionally, a serial-to-Wi-Fi gadget, a legacy device with an Ethernet port and no Wi-Fi, works fine because the traffic is sparse and the packet rates are trivial. Captive-portal and configuration scenarios, where the bridge exists temporarily to set something up, are fine because the throughput demands are minimal and brief. What does not fit: sharing an internet connection among phones and laptops, streaming video through the bridge, or anything where a user will notice the speed. For those, the right tool is actual routing hardware. A useful rule of thumb: if the bridged device's total traffic stays comfortably under a megabit or two with modest connection counts, the ESP32 handles it; if the use case involves human-perceived speed, it does not.
Tuning Within the Ceiling
For the use cases that fit, tuning squeezes the most from the limited headroom. Raise the NAT table timeout efficiency by tuning idle timeouts down for UDP, which otherwise lingers. Keep the ESP32's own application minimal: every task competing for CPU with the forwarding path lowers throughput, so a dedicated bridge build with nothing else running performs best. Pin the network tasks appropriately and give the Wi-Fi driver adequate priority, since starving the driver causes retransmissions that waste the airtime you cannot spare. Use the fastest SPI or SDIO configuration the hardware supports if an external radio or Ethernet is involved. And measure honestly: run a throughput test through the bridge under realistic traffic and compare against the requirement, because the gap between "it connects" and "it performs" is where these projects live or die.
The ESP32 is a capable endpoint and a marginal router. NAT bridging works within its limits, low bandwidth, few connections, tolerant applications, and fails outside them for reasons baked into the silicon and the Wi-Fi medium. Match the project to the ceiling and the bridge is a neat trick; exceed it and no tuning will save you.
Related Guides
- Ground Plane Shielding on ESP32 Microstrip Lines: The ESP32's Wi-Fi and Bluetooth radios live or die by the RF layout, and the microstrip traces carrying 2.4 GHz signals to the antenna are the most
- AP Station Isolation Protocols for ESP32 Mesh: ESP32 mesh networks, where each node relays for the others to extend coverage, often include an access point interface so phones, laptops, or sensors
- High-Gain Directional Wi-Fi Bridge Antennas: When an ESP32 project needs to reach across a yard, between buildings, or to the far corner of a property, the stock antenna gives up long before the
- RF Ground Plane Isolation on Directional Wi-Fi Boards: A directional Wi-Fi board, a patch antenna or a small array feeding an ESP32 bridge, lives or dies by its RF ground plane. The ground plane is part