Treat listener reachability, encrypted transport and reported client identity as three separate tasks. A correct public hostname does not bind a socket, a TLS certificate does not open a firewall, and a forwarded header is not automatically a trustworthy listener address.

Bind only what is intended

Keep a test instance on 127.0.0.1. For remote listeners, choose the real local interface or deliberately use the documented all-interface behaviour. Check IPv4 and IPv6 on the target build. Shoutcast-compatible source operation can reserve a base port and the following port; it is not needed merely because a stream uses MP3.

This KH excerpt belongs directly inside <icecast> and requires a TLS-capable build:

xml · Code example
<listen-socket>
  <port>8443</port>
  <ssl>1</ssl>
</listen-socket>

Merge these replacement paths into the existing <paths> block rather than creating unrelated duplicate blocks:

xml · Code example
<ssl-certificate>/ABSOLUTE/PATH/fullchain.pem</ssl-certificate>
<ssl-private-key>/ABSOLUTE/PATH/private-key.pem</ssl-private-key>

This is the KH layout described by its source and documentation, not the regular Icecast 2.5 TLS-context layout. Restrict private-key access while allowing the service account to read it. Use your actual certificate chain and identity.

Place a boundary around proxy headers

The documented paths/x-forwarded-for setting establishes trust in a proxy address. Configure only a known proxy under your control, and verify direct untrusted clients cannot choose arbitrary reported identities. Do not populate a trust list from request headers or treat every connecting address as a proxy. A false listener address can corrupt logs and downstream access decisions.

Verify what a listener actually uses

sh · Code example
curl --head --show-error https://stream.example.org:8443/index.html

Replace the example with your own test endpoint and check certificate verification, response and generated listening URLs. Test from the intended listener network as well as locally. If a private CA is deliberate, supply its CA file explicitly; do not hide certificate faults with a permanent verification bypass. For a proxy deployment, compare known direct/proxied test connections with the server’s observed peer data.