Events from Certain Regions are not reaching Amplitude
If events from users in a specific region stop appearing in Amplitude, the cause usually isn't your SDK setup or Amplitude's ingestion endpoints. The most common cause is DNS poisoning of Amplitude's API domains. DNS poisoning occurs when attackers inject fake information into a DNS server's cache. DNS queries then return incorrect replies, which can send users to the wrong website.
This article explains why DNS poisoning affects event delivery, how to confirm it, and how to resolve it.
Important
Amplitude can't prevent DNS poisoning because it occurs at the network level, outside Amplitude's control. For more information, refer to DNS cache poisoning.
Why events stop flowing
Amplitude's SDKs send event data to Amplitude's ingestion endpoints, typically:
https://api.amplitude.comhttps://api2.amplitude.com
These domains can be subject to DNS poisoning. When that happens:
- Devices can't resolve Amplitude's ingestion domains correctly.
- Requests to Amplitude's API endpoints fail before they leave the network.
- Events from users' devices never reach Amplitude.
How to confirm DNS poisoning
If you suspect events aren't reaching Amplitude:
- Check your event logs: Look for a sudden drop or complete stop in events from a specific region while events from other regions stay normal.
- Test DNS resolution: Resolve
api.amplitude.comfrom within the affected region. If the domain doesn't resolve correctly or points to an invalid IP, the domain is likely poisoned. - Use a different network: Send the same event from unaffected regions. If the event succeeds, the issue is region-specific.
Resolving DNS poisoning
You can't directly prevent DNS poisoning, but you can use the following strategies so events from the affected region still reach Amplitude.
Deploy a domain proxy to relay events for impacted regions
Set up a domain proxy within the affected region that forwards traffic to Amplitude. Then configure your SDK to send data to this proxy instead of api.amplitude.com.
Refer to Use domain proxy to relay events for options.
Why the solution works
- The SDK sends events to a custom domain you control (for example,
https://analytics.yourdomain.com). - That domain is hosted in that region and resolves without DNS poisoning.
- The reverse proxy forwards events to Amplitude's ingestion endpoints.
Pros
- Minimal changes to your analytics setup.
- Events are forwarded in real time with little additional latency.
Cons
- Requires infrastructure inside the affected region (or a CDN that supports reverse proxying).
- You must maintain and secure the proxy.
Route events through your own server or API
Configure your SDK to send all data to your own server endpoint rather than directly to Amplitude. This approach is similar to deploying a domain proxy, but it applies to all events, not only events from the affected regions. This approach also gives you more flexibility to store data in your preferred data warehouse and integrate with Amplitude.
Why the solution works
- The client SDK sends events to your server (for example,
https://events.yourcompany.com). - Your server ingests the events and stores the data in your infrastructure (for example, in Amazon S3).
- You set up an integration (for example, Amazon S3) with Amplitude.
- Because your server isn't blocked, data flows through even when client-side requests fail.
Pros
- Full control over data routing and retry logic.
- Easier to implement if you already have backend infrastructure.
Cons
- Slightly more complex data pipeline.
- Events may have additional latency depending on how you batch and forward them.
Related content
Was this helpful?