我试图做一个简单的事情，在 Icecast主stream服务器的前端高可用性（即我不是在谈论Icecast中继这里） 的反向代理加倍 。 那么，三个虚拟机：
我的问题是 – 如何configuration反向代理进行自动故障转移，以防Icecast虚拟机中的一个出现stream中断，并且stream客户端不中断？
插图：
/--- [ local nginx A <-> icecast master A <- mpd A] -> [nginx reverse proxy] ---< \--- [ local nginx B <-> icecast master B <- mpd B] 我第一次尝试这个简单的教程来设置一个反向代理nginx，之后我可以通过打开nginx虚拟机来听stream。
upstream backend { ip_hash; # try to send the same clients to the same servers server 1.2.3.4; server 1.2.3.5 max_fails=1 fail_timeout=15s; } server { location / { proxy_pass http://backend; } }
当我停止Icecast虚拟机上的Icecast服务，这是最终的端点，但客户端不会故障切换到好的Icecast。 出于某种原因，甚至没有刷新。 我试着尝试各种ip_hash ， max_fails ， fail_timeout选项，不同的响应标题属性，缓冲区大小等， 其他 网站 提到 ，但没有任何工作。 我感觉有点像我在黑暗中钓鱼，鉴于stream行广播电台的数量，应该有一些明显的stream式故障转移解决scheme。 有关如何最好地设置这个或一些好的资源的任何意见？ 我想要302redirect还是真正的代理通行证？
我打开基于HAProxy的build议，如果这也是一个更好的方法。
正如你发现的，反向代理Icecast不是一个好主意。 没有真正的好处，虽然有几个缺点，你仍然有一个单一的失败点：你的前端。
Icecast是一个非常稳定和可靠的服务器，通过HTTP服务网页的典型策略并不一定适用于它。
你的努力可能会更好地花在了解Icecast，它的configuration和限制。 也就是说，如果configuration正确，Icecast会轻松饱和一个1 GBit / s的连接，并且服务于超过20,000个并发监听器。 testing实际上表明，它的规模远远超出了这个范围，但是可能会出现一些情况。
之后，问自己： 我真的想要解决什么问题，并且问题的答案很可能不是“反向代理”。