初步使用v4.71的几个问题 #234
Comments
|
待会看看 stopcmd的是改了，之前会默认丢弃输出和错误，新版需要自己丢弃输出和错误了。 mainport的那个注释是给自定义dns看的，内置的不用管，默认会给设置好的。监听0.0.0.0会覆盖到本机所有网卡。 ipset报错问题，加个-x参数重新执行，看看是哪个set出的错。我这边没有遇到这个问题。 |
|
另外，stopcmd里面不需要填dns进程。填代理相关的就可以了 |
|
dnsmasq_bind_port 一般不需要去改，默认留空就好，这里提供选项是为了在dnsmasq前面加入其他dns进程(也就是说，新加入的进程监听mainport，dnsmasq监听其他端口)。 |
|
|
确实有点神奇了，我明天看看，能不能自己复现出来 |
|
这是因为iptables还没有完全停止，那么这个sstp_white 就处于被占用中，无法destroy。可能跟 iptables |
|
ipset 停止命令可以稍微优化下 while ipset list sstp_white &>/dev/null; do
ipset destroy sstp_white
done
|
应该是这个问题，开始也怀疑了，在另一台配置稍好的机器上怎么restart 也不出现这个问题。 ========== 添加了1秒延时，问题可以解决(0.2秒也行) |
|
@zfl9 还有个小问题
还能设内网私有IP吗？我的环境里有是个10.x.x.x段的Dns服务器，以前用在这里没问题，新版的设这个就无法用了 |
|
这个已解决，是一个参数设错了
|
|
ipset 那个问题，搜了下，感觉是 iptables -F 在规则被完全清理之前就返回了（命令执行完毕），你看看是不是因为用的后端是 nft（执行 |
|
看了下 iptables --version
|
|
另一个正常的机器呢？是 legacy 吗？ |
|
一样的，都是kvm虚拟机，DEBIAN 11 最小安装，只是这个出问题的机器，分配的资源弱点。 |
|
了解，那我加个处理吧，sleep 1肯定不太合适，因为对于那些不出问题的人来说，sleep 1秒太伤了。 |
|
这种问题，以前的版本也出现过，但是非常少见，多出现在把ss-tproxy装在路由器里的情况，比如用在 egdemax erx系列或unifi usg3 这些musl机型里时，后来都放在旁路x86的虚拟机里用了，在v4.6x版本中基本不会出现了再。 |
|
@bluehj777 你改一下 ss-tproxy 把 |
|
改动测试下，还是不行 |
|
出现这个问题的时候, 你立刻运行 iptables-save 看看里面是不是还有什么规则没有清理干净?
|
|
这个 sstp_white摧毁不了？ ss-tproxy stop ; ss-tproxy start ; ss-tproxy stop ; iptables-save ; ipset list -n |
|
你这个
|
|
手动执行 ipset destroy sstp_white 看看？
nft list ruleset 看看是不是这边有引用？ |
|
确保顺序还是 |
是的，还是这个顺序 ss-tproxy stop ; ipset x sstp_white ; ss-tproxy start ; ss-tproxy stop ; iptables-save ; ipset list -n |
|
|
|
ss-tproxy stop 后，手动 destroy 这个 set（或者再次执行 ss-tproxy stop），是否可以销毁？ 另外，ss-tproxy stop 后，执行 还有，start 和 stop 后，执行 |
|
算了，不必再折腾了。 你把 flush_ipset 这个函数改一下，没问题，我就提交代码了。 flush_ipset() {
for setname in $(ipset -n list | grep '^sstp_'); do
while ! ipset destroy $setname &>/dev/null; do
sleep 0.05 # 稍微等一下，避免短时间内执行太多指令
done
done
# 加个检测
if ipset -n list | grep -q '^sstp_'; then
echo "ipset 没清理干净"
fi
} |
|
已测试，加上这个处理后就没有问题了 |
|
好的。 |
有多弱? |
比没有问题的弱，4核4G内存，虚拟硬盘 |
这根本不弱. 没啥关联的. 两个系统分别都是啥? iptables --version 分别都是啥? |
都是debian11 的x64 dist-upgrade 到最新。iptables --version 都是 iptables v1.8.7 (nf_tables) 一个是pve下的虚拟机，三网卡（不同VLAN），intel x550做了vfs（相当于直通吧）这台没问题。 目前有问题的这台，加了点儿sleep确定可以无论怎么restart都没问题了，只要不加，第2次开始就出问题。但是呢我发现要是等上个1,2分钟再RESTART就没问题(也很随机)，然后再restart，就又开始。如果不用restart 用stop后在start，也是一样。出问题时ipset -n list btw:还有个问题请教。目前ss-tproxy新版的 想确定下restart 和stop/start 有什么区别？一般什么场景用restart什么用stop/start。比如我只切换代理服务器的地址(代理使用的客户端软件和其配置都不变时)，是不是只要ss-tproxy flush-dnscache就行了？ |
|
想确定下restart 和stop/start 有什么区别 restart 就是 stop 然后 start，没区别。 切换代理，重启代理进程即可。我看你用的是 xray，重启 xray 进程即可。 flush-dnscache 应该不需要，因为代理进程不使用 ss-tproxy 上的 dns 服务。使用的 dns 是 /etc/resolv.conf 里面的。 |
如果使用的是域名，并且域名没变，只是对应的 ip 变了，通常不用操作。 可以通过 |
我主要是在考虑布置一个 检测到代理服务器不可用自动切换节点 的脚本。是个单独的脚本，cron里每5分检测一下google。如果不可用就切换。预先设置好允许切换节点服务器配置的文件名，
|
代理如果断开了（不可用），也不会存在受污染的结果。因为此时解析 google 等域名，只会失败。 因此不需要担心缓存问题。当然在切换节点时，可以手动执行 flush-dnscache，主要是考虑到：新节点的地理位置与老节点不同，如果仍然使用之前的缓存结果，可能对某些cdn域名不友好（访问速度减慢），比如从亚太切换到北美节点。 |
|
嗯，明白了，非常感谢指点。 |
是的，kill xray进程，然后start新的xray进程，即可。 你可以给 xray 的 json 配置文件来个软链接，切换节点就是切换这个软链接，然后restart xray进程。 |
|
用 |
对。是这个道理，好优化。之前没想到。1.1.1.1本身比谷歌稳吧：-） |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
环境 debian11 干净安装，多网卡。chnroute 代理本机和内网，本机为网关。使用DNS内置方案
ip a
cat ss-tproxy.config
如上设置，初步测试简单测试看大体没有问题。
如下小问题：
1.这个新加的参数dns_mainport 没太看明白，监听通配地址，这里如何设置监听地址？给的例子是个53端口，我设置60053，会监听127.0.0.1和0.0.0.0的60053端口。可否让他监听192.168.100.254和192.168.30.254的60053吗？
2.较比以前的4.6x的版本，在执行ss-tproxy stop ss-tproxy restart 时候，很容易出现
ipset v7.10: Set cannot be created: set with the same name already exists
这个提示。首次ss-tproxy restart执行不出现，然后再执行，基本就会出现
3.对于proxy_stopcmd的处理。
proxy_stopcmd='kill -9 $(pidof ss-redir v2ray xray obfs-local dnsmasq chinadns-ng dns2tcp)' # 用于关闭"本机代理进程(组)"
在 ss-tproxy stop 后，再次执行ss-tproxy stop(比如手误时)。出现提示
kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec]
以前4.6x版本，是不会的。
以上是初步测试，所有问题到没有影响SS-TPROXY的使用结果。
The text was updated successfully, but these errors were encountered: