gost 是否考虑增加主备/故障转移模式？

目前已有负载均衡模式，但有些应用情景，要求一系列请求由相同ip发起。是否可以新增故障转移（节点）模式，当节点正常时不切换，故障时切换到下一个节点

Feb 01 '19 11:02 miyouzi

这个问题在 #235 中有讨论

Feb 01 '19 13:02 ginuerzh

那么假设有三个socks5代理服务: 127.0.0.1:1080 127.0.0.1:1081 127.0.0.1:1082, 三个代理出口IP不同

*.example.com 和 *.example-cdn.com 要求发起请求的IP相同.

想要实现故障转移, 以下配置是否正确:

gost -L=:8080 -F=socks5://localhost:1080?ip=127.0.0.1:1080,127.0.0.1:1081,127.0.0.1:1082?bypass=*.example.com,*.example-cdn.com

Feb 03 '19 03:02 miyouzi

看到了 #224 ，认为fifo很接近我所说的故障转移模式，但是在尝试过程中发生故障节点无法切换问题

D:\>gost -V
gost 2.7.2 (go1.11.2 windows/amd64)

D:\>gost -L=:8888 -F=socks5://127.0.0.1:1080?peer="D:\peers.json"
2019/02/12 14:03:11 route.go:464: auto://:8888 on [::]:8888
2019/02/12 14:03:29 http.go:147: [http] 127.0.0.1:53119 -> auto://:8888 -> www.ipip.net:443
2019/02/12 14:03:29 http.go:238: [route] 127.0.0.1:53119 -> auto://:8888 -> 1@socks5://127.0.0.1:1080 -> www.ipip.net:443
2019/02/12 14:03:34 http.go:259: [http] 127.0.0.1:53119 -> 127.0.0.1:8888 : read tcp 127.0.0.1:53120->127.0.0.1:1080: i/o timeout
2019/02/12 14:04:54 http.go:147: [http] 127.0.0.1:53266 -> auto://:8888 -> www.ipip.net:443
2019/02/12 14:04:54 http.go:238: [route] 127.0.0.1:53266 -> auto://:8888 -> 1@socks5://127.0.0.1:1080 -> www.ipip.net:443
2019/02/12 14:04:59 http.go:259: [http] 127.0.0.1:53266 -> 127.0.0.1:8888 : read tcp 127.0.0.1:53267->127.0.0.1:1080: i/o timeout
2019/02/12 14:06:07 http.go:147: [http] 127.0.0.1:53490 -> auto://:8888 -> www.ipip.net:443
2019/02/12 14:06:07 http.go:238: [route] 127.0.0.1:53490 -> auto://:8888 -> 1@socks5://127.0.0.1:1080 -> www.ipip.net:443
2019/02/12 14:06:12 http.go:259: [http] 127.0.0.1:53490 -> 127.0.0.1:8888 : read tcp 127.0.0.1:53491->127.0.0.1:1080: i/o timeout
2019/02/12 14:08:19 http.go:147: [http] 127.0.0.1:53698 -> auto://:8888 -> clients4.google.com:443
2019/02/12 14:08:19 http.go:238: [route] 127.0.0.1:53698 -> auto://:8888 -> 1@socks5://127.0.0.1:1080 -> clients4.google.com:443
2019/02/12 14:08:24 http.go:259: [http] 127.0.0.1:53698 -> 127.0.0.1:8888 : read tcp 127.0.0.1:53699->127.0.0.1:1080: i/o timeout

peers.json

strategy        fifo
max_fails       1
fail_timeout    600s
reload          10s
peer		socks5://127.0.0.1:1080
peer		socks5://127.0.0.1:1081
peer		socks5://127.0.0.1:1483

Feb 12 '19 06:02 miyouzi

默认如果请求失败不会重试，当节点的失败次数达到设定的max_fails值时，下一次请求就会使用新的备用节点。在-L上增加一个retry参数，会在每次失败后进行重试。 gost -L=:8888?retry=2 -F=socks5://127.0.0.1:1080?peer="D:\peers.json"

使用peer参数时，命令行中的socks5://127.0.0.1:1080会自动作为第一个节点，配置文件中就不用再重复列出。

Feb 12 '19 06:02 ginuerzh

使用了retry参数的确会自动重试，但是故障依然无法切换至下一个节点，我max_fails设置为1，理应在第一次i/o timeout后就切换到socks5://127.0.0.1:1081才对，然而并没有。

D:\>gost -L=:8888?retry=2 -F=socks5://127.0.0.1:1080?peer="D:\peers.json"
2019/02/12 16:05:11 route.go:464: auto://:8888 on [::]:8888
2019/02/12 16:06:24 http.go:147: [http] 127.0.0.1:65209 -> auto://:8888 -> www.ipip.net:443
2019/02/12 16:06:24 http.go:238: [route] 127.0.0.1:65209 -> auto://:8888 -> 1@socks5://127.0.0.1:1080 -> www.ipip.net:443
2019/02/12 16:06:29 http.go:259: [http] 127.0.0.1:65209 -> 127.0.0.1:8888 : read tcp 127.0.0.1:65210->127.0.0.1:1080: i/o timeout
2019/02/12 16:06:29 http.go:238: [route] 127.0.0.1:65209 -> auto://:8888 -> 1@socks5://127.0.0.1:1080 -> www.ipip.net:443
2019/02/12 16:06:34 http.go:259: [http] 127.0.0.1:65209 -> 127.0.0.1:8888 : read tcp 127.0.0.1:65265->127.0.0.1:1080: i/o timeout
2019/02/12 16:09:01 http.go:147: [http] 127.0.0.1:65429 -> auto://:8888 -> www.ipip.net:443
2019/02/12 16:09:01 http.go:238: [route] 127.0.0.1:65429 -> auto://:8888 -> 1@socks5://127.0.0.1:1080 -> www.ipip.net:443
2019/02/12 16:09:06 http.go:259: [http] 127.0.0.1:65429 -> 127.0.0.1:8888 : read tcp 127.0.0.1:65430->127.0.0.1:1080: i/o timeout
2019/02/12 16:09:06 http.go:238: [route] 127.0.0.1:65429 -> auto://:8888 -> 1@socks5://127.0.0.1:1080 -> www.ipip.net:443
2019/02/12 16:09:11 http.go:259: [http] 127.0.0.1:65429 -> 127.0.0.1:8888 : read tcp 127.0.0.1:65436->127.0.0.1:1080: i/o timeout
2019/02/12 16:09:20 http.go:147: [http] 127.0.0.1:65456 -> auto://:8888 -> clients4.google.com:443
2019/02/12 16:09:20 http.go:238: [route] 127.0.0.1:65456 -> auto://:8888 -> 1@socks5://127.0.0.1:1080 -> clients4.google.com:443
2019/02/12 16:09:25 http.go:259: [http] 127.0.0.1:65456 -> 127.0.0.1:8888 : read tcp 127.0.0.1:65457->127.0.0.1:1080: i/o timeout
2019/02/12 16:09:25 http.go:238: [route] 127.0.0.1:65456 -> auto://:8888 -> 1@socks5://127.0.0.1:1080 -> clients4.google.com:443
2019/02/12 16:09:30 http.go:259: [http] 127.0.0.1:65456 -> 127.0.0.1:8888 : read tcp 127.0.0.1:65464->127.0.0.1:1080: i/o timeout

peers.json

strategy        fifo
max_fails       1
fail_timeout    600s
reload          10s
peer		socks5://127.0.0.1:1081
peer		socks5://127.0.0.1:1483

Feb 12 '19 08:02 miyouzi

有可能是配置文件peers.json格式有问题没有解析出来，请查看是否为utf8编码

Feb 12 '19 08:02 ginuerzh

确认为UTF-8无Bom编码，peer与节点信息原先使用 Tab 间隔，将 Tab 换成空格依然有此问题

D:\>gost -L=:8888?retry=2 -F=socks5://127.0.0.1:1080?peer="D:\peers.json"
2019/02/12 16:39:33 route.go:464: auto://:8888 on [::]:8888
2019/02/12 16:39:35 http.go:147: [http] 127.0.0.1:4804 -> auto://:8888 -> www.ipip.net:443
2019/02/12 16:39:35 http.go:238: [route] 127.0.0.1:4804 -> auto://:8888 -> 1@socks5://127.0.0.1:1080 -> www.ipip.net:443
2019/02/12 16:39:40 http.go:259: [http] 127.0.0.1:4804 -> 127.0.0.1:8888 : read tcp 127.0.0.1:4805->127.0.0.1:1080: i/o timeout
2019/02/12 16:39:40 http.go:238: [route] 127.0.0.1:4804 -> auto://:8888 -> 1@socks5://127.0.0.1:1080 -> www.ipip.net:443
2019/02/12 16:39:45 http.go:259: [http] 127.0.0.1:4804 -> 127.0.0.1:8888 : read tcp 127.0.0.1:4819->127.0.0.1:1080: i/o timeout
2019/02/12 16:39:50 http.go:147: [http] 127.0.0.1:4848 -> auto://:8888 -> clients4.google.com:443
2019/02/12 16:39:50 http.go:238: [route] 127.0.0.1:4848 -> auto://:8888 -> 1@socks5://127.0.0.1:1080 -> clients4.google.com:443
2019/02/12 16:39:55 http.go:259: [http] 127.0.0.1:4848 -> 127.0.0.1:8888 : read tcp 127.0.0.1:4849->127.0.0.1:1080: i/o timeout
2019/02/12 16:39:55 http.go:238: [route] 127.0.0.1:4848 -> auto://:8888 -> 1@socks5://127.0.0.1:1080 -> clients4.google.com:443
2019/02/12 16:40:00 http.go:259: [http] 127.0.0.1:4848 -> 127.0.0.1:8888 : read tcp 127.0.0.1:4866->127.0.0.1:1080: i/o timeout

Feb 12 '19 08:02 miyouzi

我在mac下测试是没有问题的，稍后会在windows上再试试。

Feb 12 '19 08:02 ginuerzh

我在windows 7下使用gost 2.7.2版本是没有问题的。

Mar 16 '19 10:03 ginuerzh

我再次尝试了，gost 2.7.2，环境 Windows 10 64 bit，问题依旧 gost_bug

Mar 16 '19 14:03 miyouzi

#365 and #364

Mar 16 '19 22:03 f4nff

你好，我再测试了一下，如果我直接关闭了本地 1080 端口的 $$R 客户端，则可以正常切换

2019/03/17 11:58:41 route.go:464: auto://:8888 on [::]:8888
2019/03/17 11:58:43 http.go:147: [http] 127.0.0.1:12262 -> auto://:8888 -> ss0.bdstatic.com:443
2019/03/17 11:58:43 http.go:147: [http] 127.0.0.1:12263 -> auto://:8888 -> ss1.bdstatic.com:443
2019/03/17 11:58:43 http.go:238: [route] 127.0.0.1:12262 -> auto://:8888 -> 1@socks5://127.0.0.1:1080 -> ss0.bdstatic.com:443
2019/03/17 11:58:43 http.go:238: [route] 127.0.0.1:12263 -> auto://:8888 -> 1@socks5://127.0.0.1:1080 -> ss1.bdstatic.com:443
2019/03/17 11:58:43 http.go:147: [http] 127.0.0.1:12264 -> auto://:8888 -> www.baidu.com:443
2019/03/17 11:58:43 http.go:238: [route] 127.0.0.1:12264 -> auto://:8888 -> 1@socks5://127.0.0.1:1080 -> www.baidu.com:443
2019/03/17 11:58:44 http.go:259: [http] 127.0.0.1:12262 -> 127.0.0.1:8888 : dial tcp 127.0.0.1:1080: connectex: No connection could be made because the target machine actively refused it.
2019/03/17 11:58:44 http.go:238: [route] 127.0.0.1:12262 -> auto://:8888 -> 2@socks5://127.0.0.1:1081 -> ss0.bdstatic.com:443
2019/03/17 11:58:44 http.go:259: [http] 127.0.0.1:12263 -> 127.0.0.1:8888 : dial tcp 127.0.0.1:1080: connectex: No connection could be made because the target machine actively refused it.
2019/03/17 11:58:44 http.go:259: [http] 127.0.0.1:12264 -> 127.0.0.1:8888 : dial tcp 127.0.0.1:1080: connectex: No connection could be made because the target machine actively refused it.
2019/03/17 11:58:44 http.go:238: [route] 127.0.0.1:12263 -> auto://:8888 -> 2@socks5://127.0.0.1:1081 -> ss1.bdstatic.com:443
2019/03/17 11:58:44 http.go:238: [route] 127.0.0.1:12264 -> auto://:8888 -> 2@socks5://127.0.0.1:1081 -> www.baidu.com:443
2019/03/17 11:58:44 http.go:291: [http] 127.0.0.1:12263 <-> ss1.bdstatic.com:443
2019/03/17 11:58:44 http.go:291: [http] 127.0.0.1:12262 <-> ss0.bdstatic.com:443
2019/03/17 11:58:44 http.go:291: [http] 127.0.0.1:12264 <-> www.baidu.com:443
2019/03/17 11:58:44 http.go:147: [http] 127.0.0.1:12280 -> auto://:8888 -> ss0.baidu.com:443
2019/03/17 11:58:44 http.go:238: [route] 127.0.0.1:12280 -> auto://:8888 -> 2@socks5://127.0.0.1:1081 -> ss0.baidu.com:443
2019/03/17 11:58:44 http.go:147: [http] 127.0.0.1:12281 -> auto://:8888 -> ss1.baidu.com:443
2019/03/17 11:58:44 http.go:238: [route] 127.0.0.1:12281 -> auto://:8888 -> 2@socks5://127.0.0.1:1081 -> ss1.baidu.com:443
2019/03/17 11:58:44 http.go:291: [http] 127.0.0.1:12281 <-> ss1.baidu.com:443
2019/03/17 11:58:44 http.go:291: [http] 127.0.0.1:12280 <-> ss0.baidu.com:443
2019/03/17 11:58:45 http.go:147: [http] 127.0.0.1:12286 -> auto://:8888 -> sp1.baidu.com:443
2019/03/17 11:58:45 http.go:238: [route] 127.0.0.1:12286 -> auto://:8888 -> 2@socks5://127.0.0.1:1081 -> sp1.baidu.com:443
2019/03/17 11:58:45 http.go:291: [http] 127.0.0.1:12286 <-> sp1.baidu.com:443
2019/03/17 11:58:45 http.go:147: [http] 127.0.0.1:12289 -> auto://:8888 -> sp0.baidu.com:443
2019/03/17 11:58:45 http.go:238: [route] 127.0.0.1:12289 -> auto://:8888 -> 2@socks5://127.0.0.1:1081 -> sp0.baidu.com:443
2019/03/17 11:58:45 http.go:291: [http] 127.0.0.1:12289 <-> sp0.baidu.com:443
2019/03/17 11:58:45 http.go:147: [http] 127.0.0.1:12293 -> auto://:8888 -> sp2.baidu.com:443
2019/03/17 11:58:45 http.go:238: [route] 127.0.0.1:12293 -> auto://:8888 -> 2@socks5://127.0.0.1:1081 -> sp2.baidu.com:443
2019/03/17 11:58:45 http.go:291: [http] 127.0.0.1:12293 <-> sp2.baidu.com:443
2019/03/17 11:58:45 http.go:147: [http] 127.0.0.1:12296 -> auto://:8888 -> www.baidu.com:443
2019/03/17 11:58:45 http.go:238: [route] 127.0.0.1:12296 -> auto://:8888 -> 2@socks5://127.0.0.1:1081 -> www.baidu.com:443
2019/03/17 11:58:45 http.go:291: [http] 127.0.0.1:12296 <-> www.baidu.com:443
2019/03/17 11:58:45 http.go:147: [http] 127.0.0.1:12299 -> auto://:8888 -> www.baidu.com:443
2019/03/17 11:58:45 http.go:238: [route] 127.0.0.1:12299 -> auto://:8888 -> 2@socks5://127.0.0.1:1081 -> www.baidu.com:443
2019/03/17 11:58:45 http.go:291: [http] 127.0.0.1:12299 <-> www.baidu.com:443
2019/03/17 11:59:04 http.go:293: [http] 127.0.0.1:12263 >-< ss1.bdstatic.com:443
2019/03/17 11:59:04 http.go:293: [http] 127.0.0.1:12262 >-< ss0.bdstatic.com:443
2019/03/17 11:59:05 http.go:293: [http] 127.0.0.1:12280 >-< ss0.baidu.com:443
2019/03/17 11:59:05 http.go:293: [http] 127.0.0.1:12281 >-< ss1.baidu.com:443
2019/03/17 11:59:06 http.go:293: [http] 127.0.0.1:12299 >-< www.baidu.com:443
2019/03/17 11:59:06 http.go:147: [http] 127.0.0.1:12357 -> auto://:8888 -> clients2.google.com:443
2019/03/17 11:59:06 http.go:238: [route] 127.0.0.1:12357 -> auto://:8888 -> 2@socks5://127.0.0.1:1081 -> clients2.google.com:443
2019/03/17 11:59:06 http.go:291: [http] 127.0.0.1:12357 <-> clients2.google.com:443
2019/03/17 11:59:06 http.go:147: [http] 127.0.0.1:12362 -> auto://:8888 -> clients2.googleusercontent.com:443
2019/03/17 11:59:06 http.go:238: [route] 127.0.0.1:12362 -> auto://:8888 -> 2@socks5://127.0.0.1:1081 -> clients2.googleusercontent.com:443
2019/03/17 11:59:06 http.go:291: [http] 127.0.0.1:12362 <-> clients2.googleusercontent.com:443
2019/03/17 11:59:25 http.go:147: [http] 127.0.0.1:12416 -> auto://:8888 -> clients4.google.com:443
2019/03/17 11:59:25 http.go:238: [route] 127.0.0.1:12416 -> auto://:8888 -> 2@socks5://127.0.0.1:1081 -> clients4.google.com:443
2019/03/17 11:59:25 http.go:291: [http] 127.0.0.1:12416 <-> clients4.google.com:443
2019/03/17 11:59:46 http.go:293: [http] 127.0.0.1:12264 >-< www.baidu.com:443
2019/03/17 11:59:46 http.go:293: [http] 127.0.0.1:12296 >-< www.baidu.com:443

而如果 $$R 客户端没有关闭（即 1080 端口正在监听），但是节点是不可用的状态，则会导致无法切换的情况。发现上面可以正常切换提示的错误是connectex: No connection could be made because the target machine actively refused it.，而无法切换提示的错误是i/o timeout，是不是因为i/o timeout没有被用作切换的触发条件呢？

Mar 17 '19 04:03 miyouzi

借楼，请教个相关的问题
若采用fifo模式，自上而下，如果第一个 1.1.1.1:10000 是正常的，那么是不是所有的请求都会走第一个1.1.1.1:10000？

gost -L udp://:10000 -L tcp://:10000 -F relay+ws://:?ip=1.1.1.1:10000,2.2.2.2:10000&strategy=fifo

实际测试中发现，当有多个连接请求的时候，有些连接会出现无法连接；
就好像有些连接申请到的是第二个2.2.2.2:10000，而当前在第一个1.1.1.1:10000，所以连不上

Jul 09 '21 14:07 lzmfor

这个问题还在跟进吗？

Oct 15 '24 03:10 NietzscheX