gfw_resist_tls_proxy
gfw_resist_tls_proxy copied to clipboard
GFW-knocker
Is sleep necessary?
I've tested this without the sleep and looks like it is working for me (I've tested on a dedicated host from a provider).
Can anyone else comment the sleep function and test it? For me there was no need to sleep between fragments.
As I have learned from the documentation the base idea is to send fragments with a delay so GFW cache is cleaned and can't track and reassemble fragments to find SNI and drop or censor packet (using any method it does though). but interestingly it does not work for me with the sleep!!! I tried to make it work from yesterday, and commenting sleep made it work!
sleep is important.
@wlfvpn @ako-v which config do you use? which isp? are you behind cloudflare ip with web socket + tls? complete information of your config would be helpful
i set the sleep to 0 and still connects same for fragment length. no matter what length i set (even i tried 279) and it works. i tried many settings for sleep and length but the results are same ( by result i mean upload speed)
@GFW-knocker it looks like the filtering behind Mobile providers potentially defragment the packets but the ones in datacenters dont. I have one server in one of the isps.
I dont use cloudflare.
I brought up an nginx on another server outside and used curl.
curl -x 127.0.0.1:2500 --header "Host: youtube.com" $IP It works perfect!
sleep is important.
@wlfvpn @ako-v which config do you use? which isp? are you behind cloudflare ip with web socket + tls? complete information of your config would be helpful
Hello again.
using last version and running chmod +x pyprox.py now it works.
which isp? are you behind cloudflare ip with web socket + tls?
I am using shatel. Yes I am behind cloudflare, Also I am able to use it with GRPC configs. Thanks.