Overview
This article serves as the primary diagnostic entry point for "Connection Refused" errors occurring within an Aembit-managed workload. This error indicates a breakdown in the final hop between the Aembit Proxy and the Target Application.
Relates To
Connectivity: Workload Connectivity
Error Code:
os error 111(Connection Refused)
Causes
| Investigation Path | Criteria | Common Failure Points |
| Access Policy | Server Workload | Port or Hostname mismatch between Access Policy and target server workload. |
| Workload Health | Container Status | The application container is crashing, restarting, or not yet initialized. |
Solution
Investigation Paths
Follow these three diagnostic paths to isolate the source of the refusal.
Path 1: Application Listener Verification Confirm if the application is actually listening on the expected port within the pod/host.
Diagnostic Command:
# For K8s: Run this from the application container kubectl exec -it <pod-name> -c <app-container> -- netstat -tuln | grep <port>Analysis: If no output is returned, the application is not listening. The issue is likely an application crash or a startup failure. Check application logs for initialization errors.
Path 2: Port Mismatch Audit Verify that the port the Agent Proxy is attempting to use matches the port the application is actually using.
Diagnostic Command:
# Compare Aembit Access Policy port against the netstat output from Path 1.Analysis: If the Aembit Policy defines the target as
8080but the application is listening on port3000, the Agent Proxy will receive a refusal from the server workload. Update the Aembit Access Policy to align with the application's configuration.