Alertmanager报connection refused错误表明服务未响应连接请求，主因是进程未启动、监听地址配置错误、网络隔离或配置文件语法错误，而非端口被占用。
如果您在 Prometheus 部署中观察到 Alertmanager 报出 connection refused 错误，例如 dial tcp 127.0.0.1:9093: connect: connection refused，该错误**并不直接表明端口被占用**，而是明确指示客户端尝试连接 Alertmanager 的监听地址（默认 9093）时，**目标服务未响应连接请求**。常见原因包括 Alertmanager 进程未启动、监听地址配置错误、网络隔离或防火墙拦截，而非端口处于“已绑定但拒绝连接”的占用状态。
一、验证 Alertmanager 进程是否实际运行
该步骤用于确认 Alertmanager 是否处于活动状态。若进程不存在，则连接必然失败，与端口是否被其他程序占用无关。
1、执行命令检查 Alertmanager 进程是否存在：ps aux | grep alertmanager。
2、若输出中无 alertmanager 主进程（非仅 grep 自身），说明服务未启动。
3、若进程存在，继续检查其监听端口是否为预期值：lsof -i :9093 或 netstat -tulnp | grep :9093。
4、若命令返回空结果，表明 Alertmanager 虽运行，但未在 9093 端口监听——需检查其启动参数或配置文件中的 --web.listen-address 值。
二、检查 Alertmanager 启动参数与监听地址配置
Alertmanager 默认监听 0.0.0.0:9093，但若显式指定为 127.0.0.1:9093 或其他受限地址，Prometheus 或其他组件从外部 IP 访问时将触发 connection refused。
1、查看 Alertmanager 启动命令或 systemd service 文件，定位 --web.listen-address 参数值。
2、若该值为 127.0.0.1:9093，则仅允许本地回环访问；Prometheus 若运行于不同容器或主机，必须改为 0.0.0.0:9093 或对应网卡 IP。
3、修改后重启 Alertmanager：systemctl restart alertmanager 或重新运行二进制命令。
4、再次执行 lsof -i :9093，确认监听地址已更新为通配或目标接口。
三、排查 Prometheus 到 Alertmanager 的网络连通性
当 Alertmanager 运行且监听正确地址后，仍报 connection refused，说明中间存在网络层阻断，如防火墙、SELinux、Kubernetes NetworkPolicy 或 Pod 网络路由异常。
1、若在 Kubernetes 中，进入 Prometheus Pod 执行：telnet alertmanager-operated 9093（或使用 nc -zv alertmanager-operated 9093）。
2、若连接失败，检查 Service 是否存在且 Endpoints 正常：kubectl get endpoints -n monitoring alertmanager-operated。
3、若 Endpoints 为空，说明 Alertmanager Pod 未就绪或标签选择器不匹配；检查 Pod 状态：kubectl get pod -n monitoring -l app.kubernetes.io/name=alertmanager。
4、若 Pod 处于 CrashLoopBackOff，需进一步查看日志：kubectl logs -n monitoring alertmanager-main-0 -c alertmanager。
四、确认 Alertmanager 配置文件语法与模板有效性
Alertmanager 启动失败时可能静默退出，导致端口未监听。典型诱因是配置文件（alertmanager.yaml）或引用的告警模板（如 wechat.tmpl）存在语法错误，使进程无法完成初始化。
1、手动验证配置文件是否可解析：./alertmanager --config.file=alertmanager.yaml --test.config。
2、若报错指向某行模板文件（如 template: wechat.tmpl:7: unclosed action），说明该模板存在未闭合的 {{ }} 或语法错误。
3、临时注释掉 alertmanager.yaml 中的 templates 字段或整个模板路径，再次运行测试命令。
4、若测试通过，逐个恢复模板并验证，定位具体损坏文件并修复语法。
五、检查系统级限制与资源状态
极端情况下，内核连接数限制、OOM Killer 终止进程或磁盘满导致 Alertmanager 启动失败，均会表现为 connection refused。
1、检查系统日志中是否有 Alertmanager 被强制终止记录：dmesg -T | grep -i "killed process" | grep alertmanager。
2、检查根分区及 Alertmanager 数据目录磁盘使用率：df -h 和 df -h /var/lib/alertmanager。
3、检查当前打开文件数限制是否过低：cat /proc/$(pgrep alertmanager)/limits | grep "Max open files"；若 soft limit 小于 4096，需调整 systemd service 的 LimitNOFILE。
4、若发现 OOM 或磁盘满，清理资源后重启服务。
