How to Relay a SHOUTcast or Icecast Stream (August 2026)

Relaying is the process by which one server mirrors one or more streams from a remote server. When you relay a SHOUTcast or Icecast stream, a second (slave) server connects to your main (master) server, pulls the audio feed, and rebroadcasts it to its own listeners. This lets you distribute listener load across multiple machines and geographic locations without needing separate source encoders for each one.

If you run an internet radio station and your audience is growing, a single server will eventually hit its bandwidth or connection limit. Stream relaying solves that problem. You set up relay servers in different regions, and each one handles a portion of your listeners while serving the exact same audio.

In this guide, I’ll walk you through every method to relay a SHOUTcast or Icecast stream. We’ll cover Icecast master relays, mountpoint relays, SHOUTcast v1 and v2 relays, cross-platform relay setups, on-demand relay for bandwidth savings, and troubleshooting the most common errors.

What Is Stream Relaying?

Stream relaying means one streaming server acts as a listener on another server, receives the audio, and then serves that same audio to connected clients. Think of it as a mirror or repeater for your radio broadcast. The master server produces the stream, and the slave server copies it in real time.

Here’s how the architecture works. Your source client (like SAM Broadcaster, Mixxx, or an AutoDJ) sends audio to the master server. The slave server then connects to the master, pulls the stream over TCP (typically port 8000), and makes it available on its own mountpoints. Listeners who tune into the slave server hear identical audio with minimal delay.

Key terms you need to understand:

• Master server: The primary server that receives audio from your source encoder and serves both direct listeners and relay servers.

• Slave server: The secondary server that connects to the master, pulls the stream, and rebroadcasts it to its own listeners.

• Mountpoint: The unique path on a streaming server that identifies a specific stream (for example, /stream or /live.mp3).

• Master relay password: A special password on the master server that authorizes slave servers to pull streams automatically.

Relaying works across both Icecast and SHOUTcast platforms. Icecast can relay from another Icecast server or from a SHOUTcast server. SHOUTcast can relay from another SHOUTcast server. We’ll cover cross-platform specifics later in this guide.

Types of Stream Relays Compared

There are three main relay types you can configure: master relay, mountpoint relay, and on-demand relay. Each serves a different purpose, and understanding the differences helps you choose the right setup for your station.

Master relay automatically mirrors all non-hidden mountpoints from the master server. When you add a new stream to the master, the slave picks it up without any extra configuration. This is ideal when you want a complete mirror of your station.

Mountpoint relay lets you relay a specific stream rather than all of them. You configure the slave server to pull one particular mountpoint from the master. This gives you precise control over which streams get mirrored.

On-demand relay means the slave server only pulls the stream from the master when at least one listener is connected to the slave. When the last listener disconnects, the slave drops the connection to the master. This saves bandwidth on the link between the two servers.

Here’s how the three relay types compare:

• Master Relay: Mirrors all streams automatically. Best for full station backups. No per-stream configuration needed. Highest bandwidth use between servers.

• Mountpoint Relay: Mirrors one specific stream. Best for selective distribution. Requires manual configuration per mountpoint. Moderate bandwidth use.

• On-Demand Relay: Only pulls stream when listeners are connected. Best for cost-sensitive setups. Can be combined with master or mountpoint relay. Lowest bandwidth use.

Most stations start with a master relay for simplicity, then switch to mountpoint relays as they grow and need finer control.

How to Configure an Icecast Master Relay?

A master-slave relay is the simplest way to mirror an entire Icecast server. The slave server automatically discovers and relays all non-hidden mountpoints from the master. You only need to configure the slave side.

Here’s how to set it up step by step:

Step 1: Open the Icecast configuration file (icecast.xml) on your slave server. This file is typically located in /etc/icecast2/ on Linux or in the Icecast install directory on Windows.

Step 2: Find the <master-server> section within the <relay> block. If it doesn’t exist, add one inside the <relay> element.

Step 3: Configure these values:

<relay>
    <master-server>master.example.com</master-server>
    <master-server-port>8000</master-server-port>
    <master-update-interval>120</master-update-interval>
    <master-password>your_relay_password</master-password>
</relay>

Step 4: Set the master-update-interval in seconds. This controls how often the slave checks the master for new mountpoints. The default of 120 seconds works well for most stations.

Step 5: Set the master-password on the master server’s Icecast config. This password authorizes the slave to pull streams. It must match exactly on both servers.

Step 6: Restart the slave Icecast server to apply the changes. On Linux, run sudo systemctl restart icecast2. On Windows, restart the Icecast service.

After restarting, the slave server connects to the master and begins mirroring all public mountpoints. You can verify the relay is working by opening the slave server’s admin page (typically http://slave-server:8000/admin) and checking that the master’s mountpoints appear in the list.

How to Configure an Icecast Mountpoint Relay?

A mountpoint relay gives you control over exactly which stream gets mirrored. Instead of pulling everything from the master, the slave server connects to one specific mountpoint and makes it available locally.

This is useful when your master server hosts multiple streams but you only want to mirror one on a particular relay server.

Step 1: Open icecast.xml on your slave server.

Step 2: Add a <relay> block with a <local-mount> element. This tells Icecast to pull a specific remote stream and serve it under a local mountpoint name.

<relay>
    <server>master.example.com</server>
    <port>8000</port>
    <mount>/stream</mount>
    <local-mount>/relay-stream</local-mount>
    <on-demand>0</on-demand>
</relay>

Step 3: Set the <mount> value to the mountpoint path on the master server you want to relay (for example, /stream or /live.mp3).

Step 4: Set <local-mount> to the name you want listeners to use on the slave server. This can be the same as the source mountpoint or different.

Step 5: Set <on-demand> to 0 for an always-on relay or 1 for on-demand. We’ll cover on-demand relay in detail in a later section.

Step 6: Restart Icecast on the slave server.

You can add multiple <relay> blocks to mirror several mountpoints on the same slave server. Each block pulls one stream independently, so you can mix and match mountpoints from different master servers if needed.

How to Configure a SHOUTcast v2 Relay?

SHOUTcast v2 uses a mountpoint-like system called stream IDs (SID). Each stream on a SHOUTcast v2 server has a unique SID, and you reference that SID when setting up a relay.

If you’re using Centova Cast (a popular control panel for radio hosting), the relay setup is handled through a graphical interface. Here’s the process:

Step 1: Log in to your Centova Cast control panel for the slave server.

Step 2: Navigate to the server’s configuration and find the “AutoDJ” or “Stream” settings section.

Step 3: Disable the AutoDJ on the slave server. This is important because the relay will be pulling audio from the master, so the AutoDJ would conflict with the relay source.

Step 4: Find the relay configuration option and enter the relay URL. For SHOUTcast v2, the format is:

http://master.example.com:8000/stream/1/

The number after /stream/ is the SID of the source stream. SID 1 is the default for the first stream on a SHOUTcast v2 server.

Step 5: If the master server requires authentication, enter the relay username and password.

Step 6: Enable the relay option and save your settings.

Step 7: Restart the SHOUTcast v2 server through the control panel.

If you’re configuring SHOUTcast v2 manually (without Centova Cast), add a relayport and relayserver directive in the server configuration file (sc_serv.conf):

relayserver=master.example.com
relayport=8000

This tells the SHOUTcast v2 server to pull the default stream from the master. For specific SIDs, you may need to use the full stream URL approach depending on your SHOUTcast version.

How to Configure a SHOUTcast v1 Relay?

SHOUTcast v1 uses a simpler relay model than v2. The configuration is straightforward because v1 only supports a single stream per server instance.

Step 1: Open the SHOUTcast v1 configuration file (sc_serv.conf or sc_serv.ini on Windows).

Step 2: Add or modify these two lines:

relayserver=master.example.com
relayport=8000

Step 3: Set relayserver to the hostname or IP address of your master SHOUTcast server.

Step 4: Set relayport to the port the master server is running on. The default for SHOUTcast is 8000.

Step 5: Save the configuration file and restart the SHOUTcast v1 server.

SHOUTcast v1 relay has some limitations compared to v2 and Icecast. You cannot relay specific mountpoints (because v1 has no concept of mountpoints). The server mirrors the entire stream automatically. You also have less control over the local mountpoint name since v1 uses a fixed stream path.

One important note: SHOUTcast v1 is a legacy platform. If you’re setting up a new relay, I strongly recommend using SHOUTcast v2 or Icecast instead, as v1 no longer receives updates and has fewer configuration options.

Cross-Platform Relay: Icecast to SHOUTcast and Back

One of the most common questions I see in forums is whether Icecast and SHOUTcast can relay from each other. The short answer: Icecast can relay from SHOUTcast, but SHOUTcast cannot relay from Icecast.

Icecast relaying from SHOUTcast works well. Icecast was designed with cross-platform support in mind. To relay a SHOUTcast stream on an Icecast server, use a mountpoint relay configuration with the relay-shoutcast-metadata option enabled:

<relay>
    <server>shoutcast.example.com</server>
    <port>8000</port>
    <mount>/</mount>
    <local-mount>/sc-relay</local-mount>
    <relay-shoutcast-metadata>1</relay-shoutcast-metadata>
</relay>

The <relay-shoutcast-metadata> element tells Icecast to parse ICY metadata from the SHOUTcast source. This ensures song titles and artist information pass through correctly to listeners on the Icecast relay.

Set the <mount> value to / for SHOUTcast v1 sources, or use the stream path for SHOUTcast v2 sources (such as /stream/1/).

SHOUTcast relaying from Icecast is not supported. SHOUTcast servers can only relay from other SHOUTcast servers. If you need to get an Icecast stream onto a SHOUTcast server, you have two options.

Option one: Use a source client (like edcast or butt) to connect to the Icecast master as a listener and re-encode the audio back to the SHOUTcast server. This adds a small amount of latency but works reliably.

Option two: Use a Python relay script. There are open-source projects on GitHub that connect to an Icecast stream and rebroadcast it through a SHOUTcast server. These scripts act as a bridge between the two platforms, handling the protocol differences automatically.

For most stations, the simplest cross-platform approach is to use Icecast as the relay server platform since it can pull from both Icecast and SHOUTcast sources.

Saving Bandwidth with On-Demand Relay

On-demand relay is one of the most effective ways to cut bandwidth costs on a relay setup. When on-demand relay is enabled, the slave server only pulls the stream from the master when at least one listener is connected to the slave. When the last listener disconnects, the slave immediately drops the master connection.

Without on-demand relay, the slave server maintains a continuous connection to the master 24/7, even when nobody is listening to the slave. For stations with relay servers in different time zones or with low listener counts on certain relays, this wastes a significant amount of bandwidth.

To enable on-demand relay in Icecast, set the <on-demand> element to 1 in your relay block:

<relay>
    <server>master.example.com</server>
    <port>8000</port>
    <mount>/stream</mount>
    <local-mount>/relay-stream</local-mount>
    <on-demand>1</on-demand>
</relay>

For master relay configuration, you can set <relays-on-demand> in the main Icecast config to enable on-demand for all auto-discovered mountpoints at once:

<relays-on-demand>1</relays-on-demand>

The trade-off with on-demand relay is a brief connection delay for the first listener. When a new listener connects to the slave, the slave needs a moment to establish the connection to the master before audio starts flowing. This delay is typically under two seconds.

For stations paying for bandwidth by the gigabyte, on-demand relay can reduce inter-server bandwidth by 50% or more depending on listener patterns. I recommend enabling it on all relay servers that don’t have constant listener traffic.

Troubleshooting Common Relay Problems

Even with correct configuration, relay connections can fail. Here are the most common issues and how to fix them.

Relay not connecting. The most frequent cause is a firewall blocking the connection between the slave and master servers. Verify that the slave server can reach the master on the correct TCP port (usually 8000). Test connectivity by running telnet master.example.com 8000 from the slave server. If the connection times out, check firewall rules on both servers and any network-level firewalls between them.

Wrong port or mountpoint specified. Double-check that the port number in your relay configuration matches the actual port the master server is listening on. For mountpoint relays, verify the mountpoint path exists on the master by opening the master’s admin page and checking available mountpoints. A trailing slash or missing slash in the mountpoint path can cause the connection to fail silently.

Metadata not passing through. If listeners on the relay hear audio but song titles don’t update, the metadata passthrough may be disabled. For Icecast relaying from SHOUTcast, ensure <relay-shoutcast-metadata>1</relay-shoutcast-metadata> is set. For Icecast-to-Icecast relays, metadata should pass through automatically, but check that the source encoder is actually sending metadata.

AutoDJ conflicts. If the AutoDJ is enabled on the slave server while a relay is also active, the server may reject the relay connection or play the AutoDJ content instead of the relayed stream. Always disable the AutoDJ on any server configured as a relay slave. In Centova Cast, turn off the AutoDJ toggle before enabling the relay option.

Authentication errors. If the master server requires a relay password and the slave provides the wrong one (or none), the connection will be refused. Check the Icecast or SHOUTcast error logs for messages like “Authentication required” or “401 Unauthorized.” Verify that the master-password on the slave matches the password configured on the master exactly.

Checking error logs. Always start troubleshooting by reading the server logs. On Icecast, check the log file configured in icecast.xml (typically in /var/log/icecast2/). On SHOUTcast, check sc_serv.log in the server directory. Look for entries containing “relay” or “connection” for clues about what’s failing.

Frequently Asked Questions

Conclusion

Learning how to relay a SHOUTcast or Icecast stream gives you the power to scale your internet radio station beyond a single server. Whether you use a master relay for full mirroring, a mountpoint relay for selective distribution, or on-demand relay for bandwidth savings, the principles are the same: one server pulls audio from another and rebroadcasts it to listeners.

Start with a simple master relay if you’re new to this. Once you’re comfortable with the configuration, add on-demand relay to cut costs and mountpoint relays for granular control. Always check your server logs when something doesn’t work, and remember that Icecast can relay from SHOUTcast but not the other way around.