Radio Stream Redirects: How to Test and Fix the Final URL

Introduction: what a radio stream redirect problem looks like

The same symptom can have different causes. An old Shoutcast stream URL, for example, may redirect correctly but end at an unavailable mount point. An Icecast redirect may reach a live endpoint that a particular browser cannot play. A station website may also send visitors to one address while its player requests another. Record the exact submitted URL first, then inspect each HTTP response and test the final address independently in a suitable player. The home page describes public stream checks, but this article focuses on locating and correcting the redirect layer rather than treating every connection or playback fault as a redirect.

What the final URL means in an online radio delivery path

A public radio URL is the starting point for the delivery path. It may be published in an M3U or PLS playlist, embedded in a website player or submitted to a directory. The request first reaches that HTTP endpoint, which may redirect the client to a different hostname, protocol or path. A reverse proxy or redirect service can sit between the public address and the stream server, creating another layer to check.

The final URL is the endpoint that ultimately serves the Icecast or Shoutcast audio stream. It is not necessarily the address shown to listeners. Once the redirect chain has been followed, the player opens this endpoint and maintains its connection to receive audio. A Shoutcast stream URL and an Icecast mount point therefore need to be tested as delivery endpoints, rather than simply copied from server settings.

Redirect response versus stream response

A redirect response normally has a 3xx status and a Location header identifying the next URL. It tells the client where to request the resource, but does not itself provide the ongoing audio stream. The destination should then return a successful response, commonly a 2xx status, followed by stream data.

This distinction means that a running encoder or stream server does not prove that the public URL works. The encoder may be sending audio correctly while the proxy points to an outdated mount, or the published address may redirect to the wrong endpoint. Test each layer separately before changing the player.

Common symptoms of a radio stream redirect problem

A radio stream redirect problem can occur at the public URL, within the redirect chain, at the final audio endpoint or in the listener’s player. Distinguishing between these layers helps prevent a redirect issue being mistaken for a server, authentication or playback fault.

• The player keeps loading: this may indicate a redirect loop, an unreachable destination or a final URL that never returns an audio response. Test each response instead of assuming that the encoder, Icecast or Shoutcast server is offline.
• A playlist opens but playback fails: the playlist may contain a redirected URL that the player cannot follow, or the final destination may be a web page rather than an audio stream. An incorrect mount path is another possibility.
• A monitoring check reports the submitted URL as unreachable: the public endpoint may redirect to a host that the monitoring client cannot access. Check DNS, network access, authentication and the final host separately.
• The request loops or reaches an administration or landing page: inspect the Location header. A reverse proxy rule may point back to the public URL, an Icecast redirect may target the wrong path, or a Shoutcast stream URL may have been replaced by a website address.
• The final URL works only after manual copying: this may indicate client-specific redirect handling, URL encoding, certificate or HTTP-to-HTTPS differences, or a player that does not support the returned destination.

Run a curl redirect test to compare client responses, then verify the final URL in a player. If curl, a browser and an audio player produce different results, the cause is often related to headers, authentication, protocol compatibility or a non-audio destination rather than the redirect alone.

How to run a curl redirect test safely

Run the test from a machine that can reach the internet, using the exact public URL copied from your website, player or directory listing. Testing only localhost or an internal server name can bypass DNS, TLS, firewall and reverse-proxy layers that affect listeners. This may show that the stream server is running even when the public endpoint redirects incorrectly.

Start by inspecting the response headers without attempting to save the audio. They show the status code and any Location value returned by the endpoint:

curl -sS -D - -o /dev/null --max-time 10 "https://radio.example.invalid/listen"

Read the responses in order. A 301, 302, 303, 307 or 308 response normally indicates a redirect; the destination appears in a Location: header. A successful 2xx response means the request was accepted, but does not by itself prove that the body is playable audio. A 4xx or 5xx response points to a different fault layer, such as access control, a missing path or a proxy failure.

Repeat the request with redirect following enabled to display the headers encountered along the chain, ending at the destination reached by curl:

curl -sS -L -D - -o /dev/null --max-time 15 "https://radio.example.invalid/listen"

Compare each Location with the URL you expect listeners to use. Look for loops, an old hostname, an internal address, an unexpected protocol change or a path that no longer identifies the Icecast mount or Shoutcast stream. Use a public, non-authenticated URL in examples and logs; never paste usernames, passwords or tokens into a command or published support request.

If the flags or output differ, check the installed curl version and its local documentation before drawing conclusions. A curl redirect test provides evidence about HTTP delivery, but it does not replace testing the final endpoint in a compatible audio player.

How to read each response in the redirect chain

Read the headers one hop at a time. For each response, record the status code, Location value, hostname, scheme, port, path and query string. These URL components matter: a redirect may keep the station’s domain while changing from https to http, moving to another port or leading to a web page instead of an audio mount.

A 3xx response with one valid Location header is usually a single intentional redirect. An old HTTP address, for instance, may point to its HTTPS equivalent. Test the destination separately, then decide whether the player or directory should use that final address directly. Clients do not necessarily handle redirects in the same way: players, browsers, monitoring tools and embedded audio elements may apply different rules.

If the first destination returns another 3xx, record it as an additional hop. Several hops can indicate an unnecessary chain, such as an old hostname followed by a scheme change and then a path rewrite. A loop occurs when a URL eventually points back to itself, either directly or through another URL. If a redirect response has no usable Location value, it does not tell the client where to go and needs correction at the layer generating the response.

• Wrong resource: the final path opens a station page, playlist, login form or status endpoint rather than the intended audio stream.
• Wrong endpoint: the hostname, port or mount belongs to another station, server or environment.
• Final response: a non-redirect status ends the chain and must be tested as the actual audio endpoint.

A final 200 does not by itself prove that a player can play the audio, but it does show that the HTTP request completed successfully. A final 401 or 403 points to authentication or access policy, while 404 suggests a missing resource. A 502 or 504 indicates a gateway or upstream problem. Investigate these responses separately rather than treating them as redirect fixes.

Check whether the final destination is actually the stream

A successful redirect does not confirm that the destination is an audio endpoint. Test the final URL separately, then compare it with the URL used by the normal listener player. This checks the endpoint itself, rather than autoplay rules or codec support.

1. Inspect the final response headers and note the status code and, where supplied, the Content-Type. An ongoing audio connection should remain open instead of returning a short document.
2. Open the final URL in a media-capable client such as VLC, or another player that supports the stream format. Wait long enough to confirm that playback continues and that it carries the expected station output.
3. Test the same URL in the station’s website player or app. If the tool uses a different URL, inspect its configured source rather than assuming that it follows the same redirect chain.

Check	Evidence to record	What it tells you
Submitted URL	Original scheme, host, port and path	What directories, players or listeners were given
Redirect target	Each Location value	Where the request moves
Final response	Status, headers and content type	Whether the destination behaves like an audio endpoint
Playback result	Sustained sound and expected station output	Whether the endpoint delivers the intended service

A web page, server status document or information page may describe the station but return HTML instead of audio. An M3U or PLS file may contain a stream address, but it is a playlist rather than the audio connection itself. An Icecast redirect or Shoutcast stream URL that ends at one of these documents has reached the wrong layer. Correct the redirect target before investigating player behaviour.

Fixing the redirect at the correct layer

Once you have recorded the unwanted Location value, change the component that generates it. Repeated encoder changes will not normally remove a redirect created by the website, reverse proxy or web server. The encoder supplies audio to the stream server; it does not usually control the public URL that listeners follow.

Use the redirect source as the decision point

1. Old URL in a website or player: replace the source URL in the HTML audio element, JavaScript player, playlist, app configuration or station directory entry. Where possible, point it directly to the current audio endpoint.
2. Reverse-proxy rule: inspect the proxy’s routing and redirect rules. Correct the upstream host, port or path if the proxy is sending listeners to an old server or a web address. Make sure the proxy passes the live audio response instead of redirecting it elsewhere.
3. Web-server configuration: check the rewrite and redirect rules for the public hostname and stream path. An accidental site-wide HTTP redirect can affect an Icecast mount or Shoutcast stream URL when the stream shares a domain with the station website. Narrow the rule so that it applies only to the intended web pages, or remove it from the stream path.
4. Incorrect port or path: compare the submitted URL with the stream server’s actual public mount or endpoint. A wrong port, hostname or mount path may lead to a fallback page, control panel or another service instead of audio.
5. Obsolete target: replace a redirect target that no longer serves the station. A redirect to a human-facing page is not a working HTTP redirect audio stream, even if the page loads successfully in a browser.

Keep the delivery path short

HTTP-to-HTTPS can be a valid endpoint migration, but the final HTTPS address must still return the audio stream. If you control the players and public listings, update them to use that final address rather than retaining several historical redirects. Each additional hop creates another dependency and makes diagnosis less clear.

After making the change, repeat the curl redirect test. Record every status code and confirm that the final response remains an open audio connection. Test the same final URL in a player as well. If the endpoint is correct but access still fails, investigate authentication, server errors or player compatibility separately; those issues are not redirect fixes.

Icecast and Shoutcast checks without changing unrelated settings

When investigating a radio stream redirect problem, check the public endpoint separately from the encoder and automation system. Record the complete URL, including its scheme, hostname, port and path. Then establish whether the request first reaches a website, player, reverse proxy or streaming server.

Icecast checks

With Icecast, the redirect target should normally lead to the intended mount point, rather than only to the server’s base URL. Confirm which mount or stream path is carrying the audio, then compare it with the URL published in your player, directory listing or monitoring service. A base hostname and port may return a server page or status response instead of audio.

Check the publicly advertised hostname and whether a proxy sits in front of Icecast. Test the public URL separately from the direct server endpoint where appropriate. If the direct mount works but the public address redirects elsewhere, investigate the proxy or web-server rule rather than changing the source or encoder settings.

Shoutcast checks

For Shoutcast, verify that the published Shoutcast stream URL uses the intended public hostname and stream service port. A website domain, control-panel address or administrative port is not necessarily the listener endpoint. Follow the redirect chain and confirm that its final destination serves the expected audio stream.

Control-panel labels, directives and provider procedures vary between installations. Use the relevant Icecast, Shoutcast, hosting or proxy documentation instead of copying an unverified configuration block. Change only the setting that produces the incorrect redirect, then retest the public URL with a command-line client and a listener player.

Post-fix verification and a maintenance checklist

Once the redirect has been corrected, verify the complete public delivery path, not just the server or encoder. Begin with the originally published URL and follow each response:

curl -I -L https://radio.example/stream

Check each Location header, status code and scheme change. The final response should show the intended host, port and stream path. It should not lead to an old domain, administration page or unsuitable file. Repeat the test from a device or network outside the station’s server network, since local results can conceal DNS, firewall or proxy differences.

Open the final endpoint in the station’s normal player and confirm that it connects and produces audio. Test the original URL in the same player, as listeners use it. Check published .m3u and .pls files, website buttons and embedded players as well; one of them may still contain the previous Shoutcast stream URL or an outdated Icecast redirect.

Record the working URL, each redirect target, the response status and the test date. External monitoring can independently confirm that the public endpoint remains reachable and alert you when a confirmed connectivity problem occurs. It should complement this post-fix test, not replace it.

• Recheck the URL after any domain or DNS change.
• Review redirects when changing a proxy, server port or stream path.
• Update playlists, websites and player configurations together.
• Retest externally and retain the response chain for support records.

Sources

• Monitor Your Stream – Online Radio Stream Monitoring Plans With Instant Alerts
• Online Radio Stream Monitoring – Frequently Asked Questions – Monitor Your Stream
• Documentation and Information — Icecast
• Home Page - Shoutcast
• Media technologies on the web | MDN