关于iptables转发规则的建议 about luci-app-unblockmusic HOT 5 CLOSED

由于路由器里另有v2ray设置了全局透明代理，并且与本项目的默认iptables规则冲突，查看之后，建议如下：
修改unblockmusiciptables规则为匹配特征后直接转发到监听端口（5200或5201），避免添加全局转发链。这样可以不影响其它的全局透明代理、分流。

# $ipt_n -A cloud_music -p tcp -j REDIRECT --to-ports $PORT
# $ipt_n -I PREROUTING -p tcp --dport 80 -m set --match-set music dst -j cloud_music
$ipt_n -I PREROUTING -p tcp --dport 80 -m set --match-set music dst -j REDIRECT --to-ports $PORT

附：v2ray iptables 全局透明代理规则。

好，我去试试，你的v2ray是指服务端吧？

from luci-app-unblockmusic.

由于路由器里另有v2ray设置了全局透明代理，并且与本项目的默认iptables规则冲突，查看之后，建议如下：
修改unblockmusiciptables规则为匹配特征后直接转发到监听端口（5200或5201），避免添加全局转发链。这样可以不影响其它的全局透明代理、分流。

# $ipt_n -A cloud_music -p tcp -j REDIRECT --to-ports $PORT
# $ipt_n -I PREROUTING -p tcp --dport 80 -m set --match-set music dst -j cloud_music
$ipt_n -I PREROUTING -p tcp --dport 80 -m set --match-set music dst -j REDIRECT --to-ports $PORT

附：v2ray iptables 全局透明代理规则。

好，我去试试，你的v2ray是指服务端吧？

对路由器下游是作为服务端，转发流量到上游server。

from luci-app-unblockmusic.

由于路由器里另有v2ray设置了全局透明代理，并且与本项目的默认iptables规则冲突，查看之后，建议如下：
修改unblockmusiciptables规则为匹配特征后直接转发到监听端口（5200或5201），避免添加全局转发链。这样可以不影响其它的全局透明代理、分流。

# $ipt_n -A cloud_music -p tcp -j REDIRECT --to-ports $PORT
# $ipt_n -I PREROUTING -p tcp --dport 80 -m set --match-set music dst -j cloud_music
$ipt_n -I PREROUTING -p tcp --dport 80 -m set --match-set music dst -j REDIRECT --to-ports $PORT

附：v2ray iptables 全局透明代理规则。

好，我去试试，你的v2ray是指服务端吧？

对路由器下游是作为服务端，转发流量到上游server。

当前v2.2.2-3，代理规则由[1715173329] 、[rufengsuixing]、[binsee]进行了多次优化，可下载更新尝试。

from luci-app-unblockmusic.

由于路由器里另有v2ray设置了全局透明代理，并且与本项目的默认iptables规则冲突，查看之后，建议如下：
修改unblockmusiciptables规则为匹配特征后直接转发到监听端口（5200或5201），避免添加全局转发链。这样可以不影响其它的全局透明代理、分流。

# $ipt_n -A cloud_music -p tcp -j REDIRECT --to-ports $PORT
# $ipt_n -I PREROUTING -p tcp --dport 80 -m set --match-set music dst -j cloud_music
$ipt_n -I PREROUTING -p tcp --dport 80 -m set --match-set music dst -j REDIRECT --to-ports $PORT

附：v2ray iptables 全局透明代理规则。

好，我去试试，你的v2ray是指服务端吧？

对路由器下游是作为服务端，转发流量到上游server。

当前v2.2.2-3，代理规则由[1715173329] 、[rufengsuixing]、[binsee]进行了多次优化，可下载更新尝试。

感谢更新，新版依旧一键操作。
另外，查看路由系统日志，有以下记录：
Wed Nov 13 18:16:15 2019 daemon.info uwsgi: luci: accepted login on / for root from 192.168.11.227:5202
对比新版的iptables规则，猜测默认把所有访问路由的浏览转发到5202端口。我更改启动脚本，

	#$ipt_n -A cloud_music -p tcp -j REDIRECT --to-ports 5202
	#$ipt_n -I PREROUTING -p tcp --dport 80 -m set --match-set music dst -j cloud_music
	$ipt_n -I PREROUTING -p tcp --dport 80 -m set --match-set music dst -j REDIRECT --to-ports 5202

系统日志中，常规访问流量不再转发到5202端口：
Wed Nov 13 18:28:13 2019 daemon.info uwsgi: luci: accepted login on / for root from 192.168.11.227
因此，为了避免iptables规则有可能导致多重代理流量转发的干扰，仍然建议修改iptables规则，只需针对match标记匹配music的流量进行转发即可。

from luci-app-unblockmusic.

由于路由器里另有v2ray设置了全局透明代理，并且与本项目的默认iptables规则冲突，查看之后，建议如下：
修改unblockmusiciptables规则为匹配特征后直接转发到监听端口（5200或5201），避免添加全局转发链。这样可以不影响其它的全局透明代理、分流。

# $ipt_n -A cloud_music -p tcp -j REDIRECT --to-ports $PORT
# $ipt_n -I PREROUTING -p tcp --dport 80 -m set --match-set music dst -j cloud_music
$ipt_n -I PREROUTING -p tcp --dport 80 -m set --match-set music dst -j REDIRECT --to-ports $PORT

附：v2ray iptables 全局透明代理规则。

好，我去试试，你的v2ray是指服务端吧？

对路由器下游是作为服务端，转发流量到上游server。

当前v2.2.2-3，代理规则由[1715173329] 、[rufengsuixing]、[binsee]进行了多次优化，可下载更新尝试。

感谢更新，新版依旧一键操作。
另外，查看路由系统日志，有以下记录：
Wed Nov 13 18:16:15 2019 daemon.info uwsgi: luci: accepted login on / for root from 192.168.11.227:5202
对比新版的iptables规则，猜测默认把所有访问路由的浏览转发到5202端口。我更改启动脚本，

	#$ipt_n -A cloud_music -p tcp -j REDIRECT --to-ports 5202
	#$ipt_n -I PREROUTING -p tcp --dport 80 -m set --match-set music dst -j cloud_music
	$ipt_n -I PREROUTING -p tcp --dport 80 -m set --match-set music dst -j REDIRECT --to-ports 5202

系统日志中，常规访问流量不再转发到5202端口：
Wed Nov 13 18:28:13 2019 daemon.info uwsgi: luci: accepted login on / for root from 192.168.11.227
因此，为了避免iptables规则有可能导致多重代理流量转发的干扰，仍然建议修改iptables规则，只需针对match标记匹配music的流量进行转发即可。

iptables 可以制作多重代理吗？

from luci-app-unblockmusic.