ESP32 Wi-Fi Connected but No Data? Detect and Recover It

Why WL_CONNECTED is not enough

Connectivity is a chain. The radio must run, the station must associate, the interface must obtain IP, gateway and DNS settings, a route must work, a remote socket must open and the application protocol must receive a valid response.

WL_CONNECTED conveys only the lower levels of this chain. The fact that an IP address is available means that the settings are established; it does not signify that the latest data packets have passed, while RSSI only shows the amount of a signal received.

An Espressif issue opened in March 2025 reported Wi-Fi and BLE becoming unresponsive while the device still believed it was connected and held a valid IP. Restarting Wi-Fi recovered the unit. The issue is useful evidence that this symptom exists, but it does not prove that every connected-without-data failure has the same cause.

Build a four-layer health check

1. 1

   Association

   Keep track of the current Wi-Fi state plus the most recent connection or disconnection event along with its reason.

2. 2

   Interface

   Check the IP, gateway, and DNS configuration. Commence the LwIP socket work only after welcoming IP_EVENT_STA_GOT_IP.

3. 3

   Data plane

   Perform hostname resolution and use a bounded TCP connection to access your endpoint. While we have found ICMP ping to be useful for diagnosis purposes, it might not be allowed by the network.

4. 4

   Application

   Record the last useful acknowledgement which could be an MQTT message, authenticated HTTP health transaction, or valid encounter from your own protocol.

A production signal is generally strong when it comes from the infrastructure that the device relies on. It is not required to restart the fleet because of one or a couple of online services unavailability, but rather look for consecutive outages, wait until timeout ends, and use secondary services when applicable.

A safer approach to recovery ladder

1. 1

   Recreate application clients

   Disconnect MQTT, HTTP, WebSocket or custom sockets, create new sessions and resend subscription whenever applicable.

2. 2

   Reconnect the station

   Use WiFi.reconnect() for the Arduino or app-controlled esp_wifi_connect() of the ESP-IDF, applying a retry limit, backoff time and jitter.

3. 3

   Restart the WiFi interface

   If association and IP appear as still valid but autonomous probes keep failing, disable clients, turn off Wi-Fi, reset to station mode, and reconnect.

4. 4

   Restart the device

   The controlled reboot can be executed only when there is no success in recovery through the interfaces and only after preserving the reasons for the failure and important metrics.

Escalation is important. Anytime a device is rebooted after a failed request, downtime is confused with a fault in the device. Similarly, a reconnect approach that relies only on the disconnect event will do nothing when there are no events. For access control applications or medical or industrial devices, every reboot must also result in a product-specific safe state check.

Compact Arduino-ESP32 recovery pattern

The patterns below distinguish between link state and data plane health and keep credentials safe from a Wi-Fi session. Substitute the present example hosts with services in your operations and submit the lastHealthy parameter only after receiving an acknowledgment that is necessary for your product.

constexpr uint8_t FAIL_LIMIT = 3;
uint8_t failures = 0, radioRestarts = 0;

bool dataPlaneHealthy() {
    if (WiFi.status() != WL_CONNECTED || WiFi.localIP()[0] == 0)
        return false;

    WiFiClient client;
    bool ok = client.connect("health.example.com", 443, 2500);
    client.stop();
    return ok;  // Prefer a real application acknowledgement.
}

void recoverNetwork() {
    closeAndRecreateApplicationClients();

    if (WiFi.status() != WL_CONNECTED) {
        WiFi.reconnect();
        return;
    }

    if (radioRestarts++ < 2) {
        WiFi.disconnect(true, false); // radio off; keep credentials
        delay(250);
        WiFi.mode(WIFI_STA);
        WiFi.begin(WIFI_SSID, WIFI_PASSWORD);
        return;
    }

    persistRecoveryReason();
    ESP.restart();
}

void pollNetworkHealth() {
    if (dataPlaneHealthy()) { failures = 0; radioRestarts = 0; return; }
    if (++failures >= FAIL_LIMIT) { failures = 0; recoverNetwork(); }
}

The health check should be performed at a reasonable interval, but also have process some random jitter so that during an outage, the fleet does not end up reconnecting and opening TLS sessions at the same time. This example is a control-flow pattern rather than a generic timing policy – a battery sensor that delivers readings every hour cannot be treated in the same way as continuously monitored alarm.

Distinguish the failure before resetting anything

Telemetry that makes the next failure diagnosable

Before the commencement of every recovery phase, document the firmware versions and framework versions used, as well as the chip model, uptime, reason for reset, latest Wi-Fi event, time of acquiring IP, last application acknowledgement, IP/gateway/DNS state, RSSI level, communication channel, recovery phase, and outcome, in addition to the amount of free heap, minimum ever heap, and largest free block recorded.

Focusing only on the total number of bytes may fail to capture hidden fragmentation preventing allocation of memory for a network or TLS.

Keep event callbacks short. Record the event or push a compact message to a queue, then perform reconnect or shutdown work from the application task. Authentication failure, no-AP-found, beacon timeout and an application-requested disconnect should not all enter the same high-frequency retry loop.

Test BLE coexistence and real fault conditions

Classic ESP32 devices utilize the same 2.4 GHz RF spectrum for Wi-Fi and Bluetooth. In cases where an application relies on BLE provisioning, scanning or a continuous BLE connection, let's assess the results of Wi-Fi operating only against simultaneous BLE advertising, scanning, connected BLE with MQTT, multiple router restarts affected by BLE use and poor signal authentication process.

A malfunction limited to a specific combination is much more informative than a vague field report.

A useful laboratory campaign should also remove the AP, block only the WAN route, break DNS, take down the primary backend, interrupt long-lived sockets, increase TLS/BLE memory pressure and run a multi-day soak with scheduled failures. Record detection time, the recovery stage that succeeded, heap trends, queued-data preservation and whether application clients resumed cleanly.

Common fixes that create new problems

• Calling WiFi.begin() continuously creates connection churn and hides the event sequence.
• Rebooting after one timeout turns normal packet loss or backend maintenance into fleet instability.
• Erasing credentials during recovery converts a temporary outage into a provisioning failure.
• Maintaining sockets even after disconnection and change of IP address effectively leaves your application in a previous state even if the same IP returns.
• Disabling a power saving option or increasing the watchdog time without a rationale can mask the root cause of the failure by changing the symptoms.
• Planning a daily reboot will help to decrease the number of incidents, but will eliminate evidence, otherwise, logging is required so that further investigation can be undertaken.

Final recommendation

Stop asking only whether the ESP32 is connected to Wi-Fi. Ask whether the device can still complete the communication its job depends on.

Strong firmware includes Wi-Fi interactions along with full liveness checks, necessitates multiple proofs, rebuilds expired clients, and progresses from the station connection back to the interface reset and eventually the managed reboot. It also generates sufficient telemetry to identify an AP outage from a DNS problem, back-end issue, memory distress, and true failure of the network stack.

Official Sources

• Espressif issue #15531 — Connected-without-data report
• ESP-IDF — Wi-Fi Driver guide
• ESP-IDF — ICMP Echo API
• Arduino-ESP32 — Wi-Fi API
• ESP-IDF — RAM usage guidance