ZB Bridge P offline since 25 March 2026 - Diagnosis & Fix

Bridge Series
1

Hi Everyone,

My ZigBee Bridge P with 3.0.0 firmware went offline on 25 March 2026, around the same time that many folks on 3.1.0 were having issues. I cannot tell if my situation is the same as yours if you’re on 3.1.0, but this is what I discovered, and what worked for me.

TL;DR:
ZB Bridge P offline 10 days. Found China dispatch server having DNS issues. Tested to prove this. DNS resolved during the last test. Fixed local devices by power cycle and clearing cache

The issue:
I realised that cn-disp.coolkit.cc (the Mainland China dispatch server) failed globally. I could connect to the others: Asia, EU and US via the web, but not to China.

Ping worked - so the server was live, but anything to do with DNS failed. Tools such as dynchecker.org and nslookup.io were giving me blanks, possibly indicating timeouts beyond where I’m located - in Malaysia. VPN connections with endpoints in Japan and Singapore didn’t work either. Google DNS and Cloudflare failed.

The Idea:
I thought since the issues were on the China dispatch server, why not test a China-based public DNS.

So I tested Tencent’s DNSPod:
nslookup cn-disp.coolkit.cc 119.29.29.29

Which gave me this IP: 52.221.65.239
Verified by Ping: 191/191 packets, 0% loss
Meaning the servers are healthy

Sidenote: Malaysia Factor
Additionally for Malaysia, ISPs hijack 8.8.8.8 traffic for Google’s public DNS resolver. For example, google.com goes tro 172.217.26.142 instead of real IPs (we get a sanitised and curated version of Google instead). This is a double whammy.

Diagnostics Test:
On a laptop on the same network as the Bridge P, I added “52.221.165.239 cn-disp.coolkit.cc” to the laptop’s host file.

What this did was it forced the laptop to bypass DNS completely and force the laptop to use the China Dispatch server’s actual IP. This worked perfectly, and showed that the servers were healthy and the issue was DNS propogation failure.

The Twist:
It seems that during my tests, eWeLink servers started propogating properly, and were pushing out the correct records.

The Solution:
Clear stale caches on router and Bridge P, so that they could connect to the newly and properly resolved DNS. This was done by powering down and uplugging both the router and bridge. Replug router and let boot up and do it’s thing for three minutes, then power up the bridge. It works.

I’m not sure if it’ll work for you, but try doing a power cycle of router and device (and if need be your app) to clear your caches.

Good luck!
MeMo

2

Technical Query: Why is cn-disp.coolkit.cc a documented requirement for Asia-region devices?

The Conflict:
Aron from Sonoff Support recently stated that once a device is paired, it “saves” the regional domain (e.g., as-disp.coolkit.cc) and never needs to contact the China-based cn-disp.coolkit.cc again. However, this directly contradicts the Official ZB Bridge-P User Manual.

In the manual, under the “Wi-Fi LED indicator status” section, it explicitly instructs users that if the device fails to connect to the server (two flashes), they must ensure their ISP is not shielding cn-disp.coolkit.cc.

The Engineering Challenge:
If the device is truly independent of the China dispatch server after pairing, why is that specific domain listed as a mandatory troubleshooting requirement in the global manual?

My Evidence:
During a recent 10-day outage in Malaysia, my diagnostics proved that while the Asia service servers were live, the Bridge P remained offline because it could not resolve the DNS for cn-disp.coolkit.cc

As soon as I bypassed DNS for that specific China-based domain, the bridge restored its connection to the Asia server immediately.

Specific Questions for eWeLink Engineers:

  1. Boot-Sequence Hierarchy: Does the firmware “race” or cycle through a hard-coded list of dispatchers (starting with CN) during every power cycle or network reconnection?

  2. The Handshake Dependency: Is cn-disp the “root” dispatcher that must validate the device’s ID before it is allowed to maintain its persistent connection with the regional as-disp server?

  3. Logic Flowchart: Can you provide a high-level flowchart of the connection recovery logic to explain why a failure at the China dispatcher prevents a connection to the Asia service server?

3

Hello,

During the device pairing process, the App will send the corresponding service domain name to the device based on the account’s region. For Malaysian accounts, the device should normally connect to Asian service nodes and not access domain names from the Chinese region.

To further confirm the actual domain name sent and the device connection status, we recommend that you re-pair the gateway and submit feedback through the App immediately after pairing. We will analyze the domain name sent and device connection records during the pairing process through the App logs to locate the cause of the problem (and provide the gateway’s device ID).

Please note that re-pairing the gateway will clear all sub-devices and related scenarios under the current gateway. Please confirm whether you can accept this impact before pairing.

Thank you for your understanding and cooperation.

(Tip: To submit feedback through the App, go to Profile – Help & Feedback – Feedback – Submit feedback – check “I agree to the Privacy Policy and consent to uploading logs for troubleshooting” – click Submit)