German region servers (rpc-ger.aqara.com) unreachable from Starlink connections — TCP 443 timeout, reproducible

I am unable to log in to the Aqara Home iOS app over my home internet connection. The app returns:

Network error. Please try again. (Network–1001)

The same app on the same phone works normally over cellular data. This is not an app, account, or device issue — I have isolated it to network reachability of your German region servers, and I can reproduce it consistently.

Summary

Your German region endpoints resolve correctly but do not accept TCP connections from my Starlink internet connection. The identical request from a different German network (a hosted server) succeeds. This points to a reachability problem between Starlink egress prefixes and the Tencent Cloud infrastructure hosting your -ger endpoints.

Affected endpoints

Hostname Resolves to Notes
rpc- ger.aqara.com 162.62.2

15.19|Tencent Cloud|
|aiot-rpc-ger.aqara.com|120.53.7

1.194|via CNAME c5e994ed8a59f556- cl2.qcloudzygj.com,Tencent Cloud|

Evidence

  1. DNS resolution is correct and consistent.

Three independent resolvers all return the same address, so this is not a DNS or GeoDNS problem:

drill @127.0.0.1 rpc-ger.aqara.com → 162.62.215.19 (local recursive resolver, Unbound) drill @1.1.1.1 rpc-ger.aqara.com → 162.62.215.19 (Cloudflare) drill @8.8.8.8 rpc-ger.aqara.com → 162.62.215.19 (Google) 2. TCP 443 times out from my Starlink connection.

curl -sv -o /dev/null --max-time 8 https://rpc-ger.aqara.com * Connection timed out after 8051 milliseconds

  1. TCP 443 succeeds from a different German network.

Same command, same destination IP, run from a hosted server in Germany (IONOS, 87.106.235.103):

curl -sv -o /dev/null --max-time 8 https://rpc-ger.aqara.com * Connected to rpc-ger.aqara.com (162.62.215.19) port 443 The server is therefore up and reachable — but not from my connection.

  1. Traceroute from the Starlink connection.

Packets leave my network and traverse DE-CIX Frankfurt, then stop responding after entering the Tencent network:

traceroute to rpc-ger.aqara.com (162.62.215.19), 15 hops max 1 100.64.0.1 (Starlink CGNAT) 4 206.224.65.186 5 80.81.195.120 (DE-CIX Frankfurt) 9 11.18.189.171 (Tencent) 10-15 * * * (Note: the traceroute alone is not conclusive, as ICMP is commonly filtered. The decisive evidence is items 2 and 3 — the TCP result differs between two networks for the same destination IP.)

What I have ruled out

• DNS / GeoDNS — three resolvers return identical addresses (item 1)

• My firewall — packets egress normally; no block entries in the firewall log

• My router / Wi-Fi — reproduced on two separate SSIDs and confirmed at the router itself, not just on the phone

• The client device — the same iPhone works over cellular; general web browsing over Wi-Fi works normally

• Server availability — the endpoint accepts connections from another German network (item 3)

Is there another Starlink user who can try running curl -sv --max-time 8 https://rpc-ger.aqara.com to see if I’m the only one affected?

3 Likes

Hi there, it looks like you’re experiencing a support-related issue. We’ve automatically created a support ticket for you and will reach out via the forum email within the next two business days.

If other members have any suggestions or insights on this topic, feel free to share!

1 Like

Hello, welcome to the forum.

Hi, @Expert, does anyone have experience working with Starlink?

Take a look at the Aqara Home app under Profile → Help & Feedback → click the icon in the top right corner (sheet of paper with an upward-pointing arrow) → Agree to generate these diagnostic logs → “Generate log” button → “Copy” button

It’s best to have an AI translate what you copied. Is there anything insightful in there?

It’s probably best not to post the entire log here. But you can send it to support if it contains any issues.

Just out of curiosity: does the connection (or the ⁠curl⁠ request) succeed if you route your Starlink traffic through a VPN? That would definitely confirm that the issue is strictly tied to the Starlink IP range/routing on Tencent’s side.

2 Likes

Hi, did you manage to get this sorted out in the meantime?

I found your routing issue quite interesting and did some testing today (July 24, 2026). I ran a live TCP Port 443 traceroute using a German RIPE Atlas probe (ID 1016003) connected via Starlink. The probe follows essentially the exact same path as your trace, entering Tencent’s network via DE-CIX before reaching the destination.

However, unlike your connection, the RIPE Atlas probe successfully established a TCP connection to 162.62.215.19:443 in about 18 ms.

This indicates that there is no general routing or peering issue between Starlink Germany and Tencent Cloud. Instead, the evidence suggests that connectivity depends on the specific public Starlink IPv4 address being used. Your current CGNAT address appears to be handled differently from the address used by the RIPE probe. While the exact reason cannot be determined from these measurements alone, possibilities include IP reputation filtering, automated DDoS mitigation, or other access controls within Tencent’s infrastructure.

If the problem still exists, you could try the following: You could try to obtain a different public Starlink CGNAT IPv4 address. You might be able to trigger this by completely power-cycling your Starlink dish (unplugging it from power for a few minutes and plugging it back in). It is not guaranteed to change your public IP, but if the block is indeed tied to your current IP, getting a fresh one from the Starlink gateway might restore your connectivity to the Aqara servers.

2 Likes

Hi there,

since a few days I experience the same problem with Starling / German Aqara server on 443. In deed using a VPN everything is working great. So I guess it is like you said regarding specific IPs from Starlink IP-address range. However, I have not tried to obtain a new IP from Starlink yet.

Hello and welcome to the forum.

I took a new Measurement 203876740

It doesn’t really help, but it might be interesting.

125 Starlink connections were selected at random:

  • 118 probes reached their target.
  • 2 probes did not.
  • 5 probes did not report (yet).
2 Likes