There is something wrong with the ACL in ios.
[proxy_all]
[bypass_list]
121.41.110.161
||ipip.net
||ip111.cn
The domain rule of the ACL does not take effect. Only the IP rule takes effect. But in the log, it shows bypassed.
log:
2022-04-01T18:32:23.336375+08:00 - shadowsocks local 1.14.3 build 2022-04-01T10:24:09.261425+00:00
2022-04-01T18:32:23.343940+08:00 - shadowsocks socks TCP listening on 127.0.0.1:7778
2022-04-01T18:32:23.344313+08:00 - shadowsocks socks5 UDP listening on 127.0.0.1:7778
2022-04-01T18:32:23.961959+08:00 - created udp association for 127.0.0.1:63499
2022-04-01T18:32:24.065433+08:00 - CONNECT 1.1.1.1:53
2022-04-01T18:32:24.070625+08:00 - established tcp tunnel 127.0.0.1:62940 <-> 1.1.1.1:53 through sever 185.184.223.136:38293 (outbound: 185.184.223.136:38293)
2022-04-01T18:32:24.083928+08:00 - CONNECT myip.ipip.net:80
2022-04-01T18:32:24.124455+08:00 - established tcp tunnel 127.0.0.1:62941 <-> myip.ipip.net:80 bypassed
2022-04-01T18:32:24.415261+08:00 - CONNECT www.google.com:443
2022-04-01T18:32:24.429813+08:00 - created udp association for 127.0.0.1:50209
2022-04-01T18:32:25.532650+08:00 - established tcp tunnel 127.0.0.1:62944 <-> www.google.com:443 through sever 185.184.223.136:38293 (outbound: 185.184.223.136:38293)
2022-04-01T18:32:26.935104+08:00 - CONNECT 23.55.56.213:443
2022-04-01T18:32:26.959292+08:00 - established tcp tunnel 127.0.0.1:62946 <-> 23.55.56.213:443 through sever 185.184.223.136:38293 (outbound: 185.184.223.136:38293)
2022-04-01T18:32:27.424003+08:00 - CONNECT 121.41.110.161:80
2022-04-01T18:32:27.459131+08:00 - established tcp tunnel 127.0.0.1:62948 <-> 121.41.110.161:80 bypassed
So why you still said that it didn’t have any effects?
So why you still said that it didn’t have any effects?
对不起,我没有说明白。比如ip11.cn的ip是121.41.110.161。 我用以下的配置不生效:
[proxy_all]
[bypass_list]
||ip111.cn
ip111的结果仍然是服务器的ip,而不是本地运营商的ip。
但用以下的配置是生效的,ip111的结果也是正确的:
[proxy_all]
[bypass_list]
121.41.110.161
The logs in your previous comment showed that myip.ipip.net is already bypassed.
The logs in your previous comment showed that
myip.ipip.netis already bypassed.
实际上,ipip.net显示的结果是服务器的ip而不是本地ip,所以它并没有bypassed
Then you have to take a look at the environment that running sslocal. Maybe there is something related to the DNS nameserver setting.
I don’t think they are related. It already bypassed.
myip.ipip.net is already bypassed. There is nothing related to ACL. The only problem here is that why requests sent via sslocal was from foreign IP.
What you are talking about will only happen in protocol "dns", which is completely unrelated in this issue. Don’t make other users confused.
There is no local and remote DNS in SOCKS5 local server.
What you are talking about will only happen in protocol "dns", which is completely unrelated in this issue. Don’t make other users confused.
真的不好意思,我打扰到别人了。🥹
PS. 希望@zonyitoo 可以检视一下acl这块的代码。
I just ran both sslocal and ssserver locally on my laptop with your ACL, myip.ipip.net was bypassed as expected, and ssserver didn't show any logs about myip.ipip.net, which means that the request to myip.ipip.net was sent directly from sslocal (bypassed).
I can see the correct IP from myip.ipip.net. So I don't think there is anything related to the ACL rules here.
@Yewenyu You can try to do the same test by running a ssserver with -vvv and see if there are any connections to myip.ipip.net are made when you see bypassed in sslocal's log.
BTW, you are talking about iOS, maybe there is something related to routing? Maybe the requests sent from sslocal may be routed back to the Network Extension and then sent through another tunnel.
Client (SOCKS5: myip.ipip.net) -> `sslocal` -> (TARGET: myip.ipip.net, bypassed) -> [Network Extension] -> ?
Since we can see bypassed in log, then a TCP socket was made connected to myip.ipip.net in sslocal, for sure.
I just ran both
sslocalandssserverlocally on my laptop with your ACL,myip.ipip.netwas bypassed as expected, andssserverdidn't show any logs aboutmyip.ipip.net, which means that the request tomyip.ipip.netwas sent directly fromsslocal(bypassed).I can see the correct IP from
myip.ipip.net. So I don't think there is anything related to the ACL rules here.@Yewenyu You can try to do the same test by running a
ssserverwith-vvvand see if there are any connections tomyip.ipip.netare made when you seebypassedinsslocal's log.BTW, you are talking about iOS, maybe there is something related to routing? Maybe the requests sent from
sslocalmay be routed back to the Network Extension and then sent through another tunnel.Client (SOCKS5: myip.ipip.net) -> `sslocal` -> (TARGET: myip.ipip.net, bypassed) -> [Network Extension] -> ?Since we can see
bypassedin log, then a TCP socket was made connected tomyip.ipip.netinsslocal, for sure.
好的,我再see see,非常感谢
What you are talking about will only happen in protocol "dns", which is completely unrelated in this issue. Don’t make other users confused.
真的不好意思,我打扰到别人了。🥹
你也是想帮忙而已,也谢谢你
I just ran both
sslocalandssserverlocally on my laptop with your ACL,myip.ipip.netwas bypassed as expected, andssserverdidn't show any logs aboutmyip.ipip.net, which means that the request tomyip.ipip.netwas sent directly fromsslocal(bypassed).I can see the correct IP from
myip.ipip.net. So I don't think there is anything related to the ACL rules here.@Yewenyu You can try to do the same test by running a
ssserverwith-vvvand see if there are any connections tomyip.ipip.netare made when you seebypassedinsslocal's log.BTW, you are talking about iOS, maybe there is something related to routing? Maybe the requests sent from
sslocalmay be routed back to the Network Extension and then sent through another tunnel.Client (SOCKS5: myip.ipip.net) -> `sslocal` -> (TARGET: myip.ipip.net, bypassed) -> [Network Extension] -> ?Since we can see
bypassedin log, then a TCP socket was made connected tomyip.ipip.netinsslocal, for sure.
我发现ios不启用http代理的话,dns包就会走ss local的udp relay,然后dns包返回后,ss local并没有把解析好的ip记录到acl里面,所以acl域名规则就不生效了
Of course it won't, sslocal is just a tunnel, it won't parse your data.