Asterisk HTTP or HTTPS endpoint is unreachable or returns the wrong service

Freeze one request and its expected owner

Record timestamp and timezone, installed Asterisk version, client location, scheme, hostname, resolved address, port, configured prefix, full path, HTTP method, expected owning module, response code, TLS result and relevant server log from the same attempt. Redact credentials, cookies and tokens.

Classify the symptom precisely: name resolution failure, refused or timed-out TCP connection, TLS negotiation or trust failure, unexpected redirect, 404, 401, 403, failed WebSocket upgrade, 5xx response, or a successful HTTP exchange followed by missing application behavior. These outcomes belong to different gates.

Prove loaded configuration and registered URIs first

Capture the effective http.conf inputs and run http show status. Confirm enabled state, HTTP and HTTPS bind addresses, ports, prefix, registered URIs and redirects. Compare process ownership and local socket state without assuming that an edited file has been loaded.

If the expected URI is absent, prove the owning module is installed, loaded and separately enabled. ARI, AMI over HTTP, WebSocket consumers and metrics do not become available merely because the base listener is active. Follow the approved reload or restart path for the installed release, then recapture status.

Trace DNS, TCP and TLS before application credentials

Resolve the exact hostname from the failing client path and compare address family, route, firewall, proxy and listener scope. A local success does not prove remote reachability; a proxy response does not prove the backend listener.

For HTTPS, capture the presented chain, hostname match, validity, client trust and failure alert. Repairing an expired or mismatched certificate is different from opening a port. Do not weaken verification or switch to plaintext as the acceptance result.

Interpret prefix, route and authorization evidence

Compare the requested path with the configured prefix and the URI list from http show status. A 404 can indicate the wrong path, prefix or missing route owner. A 401 can establish that a protected route answered but still requires valid authentication. A 403 can reflect user policy, an ACL or write restriction; prove which control made the decision.

For WebSockets, retain the HTTP upgrade request and response separately from later subscription and event delivery. For ARI, prove the user and read-only policy in ari.conf; for AMI over HTTP, prove both manager and web enablement. CORS does not replace credentials or network authorization.

Repair the earliest divergence and repeat the full path

Change one evidenced mismatch: name, address, port, listener scope, firewall, TLS identity, prefix, module state, URI, credentials, ACL or read-only policy. Preserve before-and-after status and avoid enabling unrelated static, status, upload or management surfaces.

Repeat TCP, TLS, expected status, authentication, authorization, WebSocket or REST behavior and the bounded application outcome. An HTTP 200 response is not proof of event delivery, channel control, media or successful calls. No PBX, socket, certificate, credential, HTTP exchange, WebSocket, channel, packet, media stream or live call was tested for this diagnostic.

Use the client trace for outbound CURL failures

When Asterisk is the HTTP client rather than the server, use the CURL diagnostic instead of changing the built-in server.