[Icecast] Icecast2, ezstream and reverse proxy
rafaelgomes at quijaua.com.br
Fri May 23 03:58:33 PDT 2014
I use a rule in iptables and solves
iptables -A PREROUTING -t nat -p tcp -d 192.168.2.32 --dport 80 -j
REDIRECT --to-port 8000
iptables-save > /etc/iptables.up.rules
echo 'pre-up iptables-restore < /etc/iptables.up.rules' >>
Em 2014-05-23 07:44, Thomas B. Rücker escreveu:
> On 05/23/2014 09:34 AM, Hoggins! wrote:
>> Correct me if I'm wrong, but what you get from Icecast *is* HTTP.
> For a listener, Icecast is just an ordinary HTTP 1.0 server.
> For a source client Icecast used to be a non-standard extension and
> the SOURCE method. We've deprecated this in 2.4.0 and now support PUT.
> He's trying to connect a source through a reverse proxy.
>> Anyway, we use proxying because on our server, some of our clients
>> cannot connect to port 8000 without bypassing their company firewall,
> The preferred method here is to make icecast bind to port 80.
>> and we don't have the possibility to add another public IP.
> That sucks, but is not an Icecast problem, dirty workarounds ensue.
>> So with
>> Apache, here is what we do :
> <snip />
> Make sure you have a _high_ number of MaxClients or your Apache will
> throw a fit after the first few listeners connect and not serve your
> websites anymore.
> Also Apache is not that great at handling many long-lived connections.
> If you really know how to set up an high performance reverse proxy, you
> won't have to ask how to handle Icecast, everyone else should really
> avoid this kind of setup.
>> And it works like a charm, and allows us to benefit from the HTTP 1.1
>> "Host" header, and use it in a virtual host.
>> The filter simply rewrites the listening URL served by the Icecast
>> to routable addresses and routable ports.
> It will break some features of the web interface, unless you start
> messing with the replies on the fly.
> Also your Icecast logs will be mostly worthless.
>> I would agree this is not the most elegant way to do, but we don't
>> a choice here.
> You have a choice, but decided to accept the trade-off. You always have
> a choice.
>> Cheers !
>> Le 23/05/2014 10:59, "Thomas B. Rücker" a écrit :
>>> On 05/21/2014 10:51 PM, David Hendry wrote:
>>>> Ezstream is working well locally with Icecast2 on port 8000 on a
>>>> Debian Wheezy platform. However, I use a reverse proxy (Pound) to
>>>> pass all requests from the Internet for x.mysite.com to backend
>>>> localhost:8000 i.e. my Icecast2 server.
>>> The short answer is: don't put Icecast behind a reverse proxy.
>>>> This works fine, i.e. x.mysite.com brings up the Icecast2 Status
>>>> page. My problem is with the ezstream xml configuration <url></url>
>>>> setting which must have a port number, and if I put
>>>> <url>x.mysite.com:8000</url> icecast2 does not get the stream. If I
>>>> use NAT on my router to bypass the reverse proxy, x.mysite.com:8000
>>>> goes straight to Icecast2 and everything works; but I don't want to
>>>> do it this way. Do you have any ideas as to what I can do to get
>>>> ezstream working with icecast2 and my reverse proxy?
>>> You are trying to put non-HTTP traffic through a HTTP reverse proxy,
>>> not the least surprised that this fails.
>>> There /might/ be a slim chance to get things working better if you
>>> switch to Icecast 2.4.0 AND use a source client that uses PUT instead
>>> SOURCE. But only if the reverse proxy supports PUT.
>>> Your reverse proxy might still have problems with the long-lived TCP
>>> connections and other things specific to Icecast.
>>> Icecast mailing list
>>> Icecast at xiph.org
>> Icecast mailing list
>> Icecast at xiph.org
> Icecast mailing list
> Icecast at xiph.org
More information about the Icecast