Block Tuya Devices From the Internet Without Losing Control

You’ve got LocalTuya or tuya-local working. Your Tuya Wi-Fi devices respond to Home Assistant without touching the cloud for day-to-day control. The obvious next step is to cut the cord entirely, block the device’s internet access at the router, and be done with it.

Try that and, for a lot of people, the device goes unresponsive within a couple of minutes. Not just to the Tuya app. To LocalTuya too. The thing that was supposed to still work locally now doesn’t work at all.

That’s not a bug in your firewall rule. It’s Tuya’s own connection-monitoring design doing exactly what it’s supposed to do, just not in the direction you wanted.

If you’re at this stage, you’ve likely already read up on what Tuya’s cloud actually collects and decided the telemetry isn’t worth it. This piece is the practical follow-through on that decision, not the argument for making it.

The naive block breaks more than it fixes

The instinct is reasonable. The device has a local_key, LocalTuya talks to it over the LAN, so internet access should be irrelevant to local control. In practice, a lot of Tuya Wi-Fi firmware doesn’t distinguish between no internet and device is fine, just isolated. Some firmware treats the loss of its cloud connection as a signal to reset internal state, drop its local command listener, or both.

The result, reported in the make-all/tuya-local GitHub discussion thread covering this exact scenario, is a device that still answers pings and still shows up on the network, but won’t respond to local_key-based commands or complete Tuya’s local pairing flow. Community members call this the zombie state, and the name fits: alive on the LAN, dead to local control.

Why Tuya devices need a heartbeat at all

The mechanism behind this is documented, just not where most people look. Tuya’s own MQTT protocol documentation for OEM device firmware — the Tuya MQTT Standard Protocol on developer.tuya.com, aimed at firmware engineers implementing Tuya’s SDK rather than end users — specifies a recommended 60-second heartbeat interval between device and cloud. The cloud platform marks a device offline after missing 1.5 heartbeat cycles, roughly 90 seconds, with the timer resetting on every successful PING.

That’s developer documentation, not consumer support material — which is probably why it’s never made it into the troubleshooting threads people actually find when searching for this problem. Those threads describe the same behavior with vague timing, something like goes offline after a few minutes, without tying it to anything concrete. The 60-second interval and ~90-second offline threshold are the closest thing to a documented mechanism behind that vagueness.

Worth being straight about the limits of that connection, though: community-reported timings don’t line up precisely with the spec. The make-all/tuya-local discussion thread on this exact scenario reports a device going unresponsive after roughly five minutes, not 90 seconds. That’s a real gap, not a rounding error. The heartbeat spec is the most plausible documented mechanism behind the zombie state — cloud platforms commonly build in retry/backoff behavior beyond a bare keep-alive timeout, which would stretch the practical timeline past the raw spec number — but treat it as a likely explanation, not a stopwatch-verified match.

The zombie state: half-blocked is worse than not blocked

Here’s the part that trips people up. If you block outbound internet access but leave DNS resolution untouched (or the reverse — block DNS to Tuya’s servers but leave the outbound path open), the device can end up in an inconsistent state. It knows it can’t reach the cloud and its firmware reacts to that loss of heartbeat, but it never gets a clean, fail-immediately signal the way it would from a fully severed connection.

The practical effect, per the tuya-local discussion thread, is that partial blocks are frequently worse than no block at all. A device that can’t resolve DNS but can still attempt outbound connections may spend cycles retrying, timing out, and cycling its network stack in ways that also disrupt the LAN-side command listener LocalTuya depends on.

The fix isn’t blocking less. It’s blocking both paths at once, deliberately, and in the right order.

Pair first, block second

The sequence that actually works has the device complete its cloud-connected setup first, extract its local_key through LocalTuya or tuya-local’s pairing flow, confirm local control works, and only then apply the block.

This matters because the device needs at least one live internet session to hand over its local_key in the first place. Block internet access before pairing and there’s nothing for LocalTuya to extract. This is the most common reason a first attempt at going fully offline with Tuya fails outright, not the zombie state, just a device that was never able to complete its initial handshake.

Once the local_key is captured and verified working, block both the outbound internet route and DNS resolution to Tuya’s domains for that device at the same time, not one after the other with a gap in between.

What blocking still doesn’t fix

This isn’t a fully solved problem for every device, and it deserves saying plainly rather than implying a clean permanent fix exists. Per the tuya-local discussion thread, some devices lose their reported state after a power loss or reboot while offline. Their DPS (data point) values return empty until they get a brief reconnect to Tuya’s cloud to resynchronize. After that, local control resumes normally, but the reconnect step is a manual or scripted intervention, not something LocalTuya handles on its own.

If your setup has devices on switched outlets or that see frequent power blips, plan for this. A permanent block you can forget about isn’t what the current tooling delivers for every device category.

How consistently this shows up across different Tuya OEM firmware builds isn’t something this piece can pin down precisely. Treat it as a real, reported failure mode worth planning around rather than a universal guarantee that every device will behave identically.

Three ways to actually block Tuya’s cloud

Once a device’s local_key is captured and verified, three practical methods cut off its cloud path.

• Pi-hole or AdGuard Home domain blocking. Add Tuya’s cloud domains to a blocklist so DNS queries fail cleanly. Quick to set up and easy to reverse, but only blocks by hostname, not by IP, so it misses devices that hardcode an IP address rather than resolving one.
• Firewall rules keyed to device MAC address. More precise than DNS blocking alone and catches hardcoded-IP cases, but requires maintaining rules per device and reapplying them if a device gets a new DHCP lease without a reservation.
• A dedicated IoT VLAN with no internet route. Put Tuya Wi-Fi devices on their own VLAN (something like a 192.168.10.0/24 iot.lan segment), give it a local-only DNS resolver, and don’t route it to the internet at all. This holds up best over time and matches this site’s existing IoT segmentation approach, since it blocks DNS and outbound traffic in one config change instead of two separate rules that can drift out of sync.

Worth knowing: whichever method you pick, apply it after pairing, and apply the DNS and outbound blocks together. Doing them separately, even minutes apart, reopens the zombie-state window described above.

Where this doesn’t apply

Two categories of Tuya-branded devices sit outside this whole discussion.

The first is Tuya Zigbee devices running through Zigbee2MQTT or ZHA. Those never talk to Tuya’s cloud at all once paired to a coordinator — there’s no heartbeat to disrupt because there’s no cloud connection to begin with. Everything above is specific to Tuya’s Wi-Fi devices, the ones that use LocalTuya or tuya-local over MQTT-based cloud connectivity.

The second is cameras, video doorbells, and similar device categories, where core functionality — video processing, cloud storage, remote-access relay — is commonly built around Tuya’s cloud rather than a local_key command channel. The blocking sequence in this piece is written for Wi-Fi switches, plugs, sensors, and similar local_key-based devices; whether it extends cleanly to camera and doorbell categories is a separate, device-specific question this piece hasn’t verified. If you’re trying to block cloud access on one of these, confirm locally that the specific function you care about — live view, recording, motion alerts — still works before committing to a permanent block, rather than assuming the switch/plug playbook transfers directly.

I think Tuya’s own documentation is partly to blame for how much confusion this causes. The heartbeat spec that explains the zombie state exists in Tuya’s developer documentation, aimed at firmware engineers — but nothing in the consumer-facing app or support material connects that spec to what happens when a curious owner blocks the wrong combination of ports at their router.

Frequently asked questions

Why did my Tuya device stop responding after I blocked its internet access?
Most likely a partial block — outbound traffic cut but DNS still resolving, or the reverse. Block both paths together, not separately, and only after the device has already completed cloud pairing once.

Do I need to block DNS as well as internet access for Tuya devices?
Yes. Blocking only one of the two commonly triggers the zombie state described above rather than a clean offline mode.

Can Tuya devices work completely offline after the initial setup?
For most Wi-Fi switch, plug, and sensor categories, yes, once the local_key is extracted. Some devices need a brief reconnect after a reboot or power loss to resynchronize state. Camera and video-doorbell categories are a separate, unverified case — don’t assume the same playbook applies.

Will blocking Tuya’s cloud break Alexa or Google Home integration for these devices?
Yes, for any integration path that routes through Tuya’s cloud API rather than a local bridge. If voice-assistant integration matters to you, factor that into whether full blocking is worth it for a given device.

Does putting Tuya devices on a VLAN with no internet route break local control?
Not if the local_key was already extracted before the VLAN’s internet route was removed, and the VLAN’s local DNS resolver is reachable from whatever host runs LocalTuya or tuya-local.

Chinese-language hobbyist blogs on platforms like GitCode’s blog subdomain are still publishing new 摆脱云依赖 (escaping cloud dependency) guides for Tuya devices as of this writing, which suggests this specific pairing-then-blocking sequence is still a live pain point rather than a solved one people have stopped writing about.