Introduction

A monitoring migration can move host collection to a new Zabbix proxy while agents still report active checks to the old one. The new monitoring stack appears healthy, but fresh metrics never arrive through the intended proxy, one server checks in through the new path while another still talks to the previous proxy, or visibility fails only after the old proxy is shut down because agent config, included fragments, and automation often change at different times.

Treat this as an active-check target problem instead of a generic Zabbix outage. Start by checking which proxy or server address an affected agent actually uses at runtime, because migrations often validate the new proxy from the Zabbix frontend while live agents continue following older ServerActive or related settings.

Symptoms

  • A Zabbix agent still reports to the old proxy after migration
  • The new proxy is healthy, but active checks or fresh metrics never arrive there
  • One host reports through the new proxy while another still uses the previous one
  • Monitoring gaps appear only after the old proxy is restricted or retired
  • Passive checks may still work, but active reporting follows the wrong path
  • The issue started after moving Zabbix proxies, server roles, or monitoring network topology

Common Causes

  • The agent ServerActive setting still points to the old proxy or server
  • Configuration management, golden images, or host bootstrap scripts keep restoring the retired target
  • Included config fragments, package defaults, or host-local overrides still preserve the previous active-check target
  • DNS aliases or firewall rules still make the old proxy the easiest reachable destination to keep using during migration confusion
  • The frontend was updated to show the new proxy path, but agent endpoint changes never reached the host config on all systems
  • Validation confirmed the new proxy existed but did not verify where active agent traffic actually connected

Step-by-Step Fix

  1. Capture one affected host and record the agent version, active server target, hostname value, and proxy path it actually uses, because the live reporting target determines where host telemetry really lands.
  2. Compare that active reporting path with the intended post-migration monitoring design, because one stale agent setting can keep a whole host set tied to the retired proxy.
  3. Review local agent config, included config fragments, configuration-management templates, golden images, and DNS dependencies for references to the old proxy, because Zabbix agent routing depends on both local settings and deployment automation.
  4. Check active and passive target settings separately on each affected host, because one can be updated while the other still points to the previous monitoring path.
  5. Update the authoritative agent configuration and automation template so affected hosts report to the intended proxy, because registering the new proxy in Zabbix alone does not retarget existing agents.
  6. Restart the affected agent and run a controlled check-in or test item, because a running service does not prove the right proxy receives active traffic.
  7. Confirm the intended proxy now receives fresh data and last-seen updates from the migrated host, because dashboard visibility can lag behind the actual reporting path.
  8. Verify the old proxy no longer receives active agent connections from migrated hosts, because split monitoring paths can remain hidden while both proxies stay reachable.
  9. Document which team owns Zabbix agent configuration, bootstrap automation, and migration validation so future proxy cutovers verify the actual runtime reporting target before retiring the previous proxy.