Do you know which IIS components I need to expose an Icecast server and a small website publicly from Windows, and how to configure the bindings and proxy settings for it?

Hi @Lavender Haze Coleman ,Thanks for sharing your details!

After looking around, the first thing we need to understand is the difference between network exposure and what IIS actually does:

Icecast itself is a complete streaming server. When you’ve gotten it working on localhost and your encoder connects successfully, that part is done then Icecast already serves streams. To make it reachable from the public internet you need network configuration, not IIS features.

On Windows, that means making sure Icecast is listening on an appropriate interface (not just localhost), allowing the Icecast port through Windows Firewall, and (if you’re behind a NAT/router) forwarding the public port to your Windows machine.

That’s how most services get exposed publicly, router firewall + Windows firewall + service listening on an external address. This is separate from web server functionality. You can see the basic Icecast setup documentation that talks about listen sockets and ports here:

• https://www.icecast.org/docs/icecast-trunk/basic_setup/

Now, what IIS does is serve HTTP(S) content and if you install extra modules it can act as a reverse proxy. Out of the box, IIS just hosts websites. To turn it into a reverse proxy, you need two add-ons:

• URL Rewrite; Setup IIS with URL Rewrite
• Application Request Routing (ARR)

Once these are in place, you can configure IIS so that it accepts public requests on port 80/443 and forwards (proxies) them to Icecast running on a non-standard port (e.g., 8000).

In practice, you’d go into IIS Manager, enable “Enable Proxy” under the ARR settings, and then add a rewrite rule that takes incoming requests and sends them to your Icecast instance on localhost. There are examples in community guides showing how to do this with other backends, which illustrate it’s not specific to any one application:

• https://community.grafana.com/t/use-iis-with-url-rewrite-as-a-reverse-proxy-err-too-many-redirects/90894

Disclaimer: Some of these are non-Microsoft websites. The pages appear to be providing accurate, safe information. Watch out for ads on the site that may advertise products frequently classifies as a PUP (Potentially Unwanted Products). Thoroughly research any product advertised on the site before you decide to download and install it.

With that being said, I found that:

• IIS is optional for exposing Icecast. You don’t need it to make Icecast public. If you simply open/forward Icecast’s port (e.g., 8000) through your router and allow it in Windows Firewall, clients on the internet will be able to reach it directly because Icecast is already an HTTP server itself.
• Using IIS as a reverse proxy makes sense if you want one public hostname/port for both your website and the Icecast stream, or if you want IIS to terminate HTTPS and hand off plaintext traffic internally. But it adds complexity and configuration work that isn’t strictly necessary just to expose the service. Reverse proxies aren’t magical networking tools, they simply forward traffic once it’s already reachable on a public interface.
• Finally, about bindings and port conflicts: as long as Icecast and IIS listen on different ports, they won’t conflict. IIS can have your standard HTTP/HTTPS ports, and Icecast can keep its own port. If you choose to reverse-proxy everything through IIS, you bind IIS to your public ports and let it forward to Icecast internally.

Hope this helps! If you have any questions, please feel free to comment below.