Betrachten Sie Hörer-Erreichbarkeit, verschlüsselten Transport und gemeldete Clientidentität als drei Aufgaben. Ein richtiger öffentlicher Hostname bindet keinen Socket. Ein TLS-Zertifikat öffnet keine Firewall. Ein weitergeleiteter Header liefert nicht automatisch eine vertrauenswürdige Höreradresse.

Nur beabsichtigte Schnittstellen binden

Halten Sie eine Testinstanz auf 127.0.0.1. Wählen Sie für entfernte Hörer die richtige lokale Schnittstelle oder bewusst das dokumentierte Verhalten ohne Schnittstellenbegrenzung. Prüfen Sie IPv4 und IPv6 am Zielbuild. Shoutcast-kompatibler Source-Betrieb kann Basis- und Folgeport belegen. Das ist nicht allein wegen eines MP3-Streams erforderlich.

Dieser KH-Ausschnitt gehört unmittelbar in <icecast> und benötigt einen TLS-fähigen Build:

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

Fügen Sie diese zu ersetzenden Pfade in den vorhandenen <paths>-Block ein, statt unverbundene doppelte Blöcke zu erzeugen:

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

Das ist die in KH-Quellen und Dokumentation beschriebene Anordnung und nicht der TLS-Kontext von regulärem Icecast 2.5. Begrenzen Sie den Zugriff auf den privaten Schlüssel und erlauben Sie dem Dienstkonto das Lesen. Verwenden Sie Ihre tatsächliche Zertifikatskette und Identität.

Proxyheader mit einer Vertrauensgrenze versehen

Die dokumentierte Einstellung paths/x-forwarded-for legt Vertrauen in eine Proxyadresse fest. Hinterlegen Sie nur einen bekannten Proxy unter Ihrer Kontrolle. Unberechtigte direkte Clients dürfen gemeldete Identitäten nicht beliebig vorgeben. Erzeugen Sie die Vertrauensliste nicht aus Anfrageheadern und behandeln Sie nicht jede Gegenstelle als Proxy. Falsche Höreradressen verfälschen Logs und nachgelagerte Zugriffsentscheidungen.

Den tatsächlichen Hörerzugang prüfen

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

Ersetzen Sie das Beispiel durch Ihren Testendpunkt und prüfen Sie Zertifikat, Antwort und erzeugte Hörer-URLs. Testen Sie aus dem vorgesehenen Hörernetz sowie lokal. Geben Sie bei einer bewusst privaten CA deren CA-Datei an. Verdecken Sie Zertifikatsfehler nicht durch dauerhaft abgeschaltete Prüfung. Vergleichen Sie bei Proxybetrieb bekannte direkte und weitergeleitete Testverbindungen mit den beobachteten Gegenstellendaten des Servers.