shadowsocks-rust icon indicating copy to clipboard operation
shadowsocks-rust copied to clipboard

Published 20 hours ago • verified publisher icon shadowsocks

使用 blake3 系列的加密方式会导致端口被临时屏蔽

Open pexcn opened this issue 3 years ago • 29 comments

服务端版本：shadowsocks-rust v1.15.0-alpha.8 客户端版本：shadowsocks-android v5.3.1-preview

操作过程：

  1. 先在服务端启动 ssserver 进程，监听一个端口，如 1234
  2. 在本地使用 tcping -t <ip> <ss_port> 来持续 ping ssserver 的端口，可以发现端口一直是通的
  3. 使用 shadowsocks-android 连接服务端，并在客户端测试连接，第一次是通的，之后就不通了
  4. 同时本地的 tcping 的日志输出也发现 ping 的端口超时
  5. 持续几分钟后，端口又通了

备注：

  1. 测试了 2022-blake3-aes-128-gcm, 2022-blake3-aes-256-gcm, 2022-blake3-chacha20-poly1305 这几种加密，都存在这个问题
  2. ~~测试了 chacha20-ietf-poly1305, aes-128-gcm 无此问题~~ （刚刚又测试了，chacha20-ietf-poly1305 也受影响）
  3. 手上有几个 VPS, 只有其中一个 VPS 能复现这个问题，其余正常

服务端日志：

username@HOSTNAME ~ # ssservice server --server-addr 0.0.0.0:1234 --password <password_with_base64_encode> --encrypt-method 2022-blake3-aes-128-gcm --timeout 3600 --udp-timeout 300 --udp-max-associations 1024 --nofile 1048576 --tcp-keep-alive 300 --tcp-fast-open --tcp-no-delay -U -vvv
2022-10-01T16:47:48.441385847+08:00 TRACE [2204:140650083496784] [shadowsocks_rust::service::server] Config { log: LogConfig { level: 3, format: LogFormatConfig { without_time: false }, config_path: None }, runtime: RuntimeConfig { worker_count: None, mode: MultiThread } }
2022-10-01T16:47:48.442072866+08:00 INFO  [2204:140650083496784] [shadowsocks_rust::service::server] shadowsocks server 1.15.0-alpha.8 build 2022-09-30T16:24:35.097955532+00:00
2022-10-01T16:47:48.442286746+08:00 TRACE [2204:140650083496784] [shadowsocks_service::server] Config { server: [ServerConfig { addr: SocketAddr(0.0.0.0:1234), password: "<password_with_base64_encode>", method: AEAD2022_BLAKE3_AES_128_GCM, enc_key: [102, 114, 101, 101, 100, 111, 109, 95, 110, 111, 116, 95, 102, 114, 101, 101], timeout: Some(3600s), identity_keys: [], user_manager: None, plugin: None, plugin_addr: None, remarks: None, id: None, mode: TcpAndUdp, weight: ServerWeight { tcp_weight: 1.0, udp_weight: 1.0 } }], local: [], dns: System, ipv6_first: false, ipv6_only: false, no_delay: true, fast_open: true, keep_alive: Some(300s), nofile: Some(1048576), outbound_fwmark: None, outbound_bind_interface: None, outbound_bind_addr: None, inbound_send_buffer_size: None, inbound_recv_buffer_size: None, outbound_send_buffer_size: None, outbound_recv_buffer_size: None, manager: None, config_type: Server, udp_timeout: Some(300s), udp_max_associations: Some(1024), acl: None, security: SecurityConfig { replay_attack: SecurityReplayAttackConfig { policy: Default } }, balancer: BalancerConfig { max_server_rtt: None, check_interval: None, check_best_interval: None }, config_path: None, worker_count: 1 }
2022-10-01T16:47:48.444742732+08:00 TRACE [2204:140650083496784] [shadowsocks::dns_resolver::trust_dns_resolver] initializing DNS resolver with system-config ResolverConfig { domain: None, search: [], name_servers: NameServerConfigGroup([NameServerConfig { socket_addr: 8.8.8.8:53, protocol: Udp, tls_dns_name: None, trust_nx_responses: false, bind_addr: None }, NameServerConfig { socket_addr: 8.8.8.8:53, protocol: Tcp, tls_dns_name: None, trust_nx_responses: false, bind_addr: None }, NameServerConfig { socket_addr: 8.8.4.4:53, protocol: Udp, tls_dns_name: None, trust_nx_responses: false, bind_addr: None }, NameServerConfig { socket_addr: 8.8.4.4:53, protocol: Tcp, tls_dns_name: None, trust_nx_responses: false, bind_addr: None }, NameServerConfig { socket_addr: [2001:4860:4860::8888]:53, protocol: Udp, tls_dns_name: None, trust_nx_responses: false, bind_addr: None }, NameServerConfig { socket_addr: [2001:4860:4860::8888]:53, protocol: Tcp, tls_dns_name: None, trust_nx_responses: false, bind_addr: None }, NameServerConfig { socket_addr: [2001:4860:4860::8844]:53, protocol: Udp, tls_dns_name: None, trust_nx_responses: false, bind_addr: None }, NameServerConfig { socket_addr: [2001:4860:4860::8844]:53, protocol: Tcp, tls_dns_name: None, trust_nx_responses: false, bind_addr: None }]) } opts ResolverOpts { ndots: 1, timeout: 5s, attempts: 2, rotate: false, check_names: true, edns0: false, validate: false, ip_strategy: Ipv4AndIpv6, cache_size: 32, use_hosts_file: true, positive_min_ttl: None, negative_min_ttl: None, positive_max_ttl: None, negative_max_ttl: None, num_concurrent_reqs: 2, preserve_intermediates: true, try_tcp_on_error: false }
2022-10-01T16:47:48.447461234+08:00 INFO  [2204:140650083496784] [shadowsocks_service::server::tcprelay] shadowsocks tcp server listening on 0.0.0.0:1234, inbound address 0.0.0.0:1234
2022-10-01T16:47:48.447726474+08:00 INFO  [2204:140650083496784] [shadowsocks_service::server::udprelay] shadowsocks udp server listening on 0.0.0.0:1234
2022-10-01T16:48:03.500935403+08:00 TRACE [2204:140650083496784] [shadowsocks::relay::tcprelay::crypto_io] generated AEAD cipher salt b"\xeb\xf2rL\xa3f\xe9Si\xf3h\x82E\x17\xe1#"
2022-10-01T16:48:03.501808928+08:00 TRACE [2204:140650076162848] [shadowsocks::relay::tcprelay::aead_2022] got AEAD salt b"(\xa3/mM\xa6,\xeef\xd9\xe8\xda\x9cs7\'"
2022-10-01T16:48:03.502213594+08:00 TRACE [2204:140650076162848] [shadowsocks::relay::tcprelay::aead_2022] got AEAD header stream_type: 0, timestamp: 1664614083, length: 53, request_salt: None
2022-10-01T16:48:03.502302423+08:00 TRACE [2204:140650076162848] [shadowsocks_service::server::tcprelay] accepted tcp client connection <local-client-ip>:40444, establishing tunnel to dns.google:53
2022-10-01T16:48:03.502463454+08:00 DEBUG [2204:140650076162848] [trust_dns_proto::xfer::dns_handle] querying: dns.google A
2022-10-01T16:48:03.502628239+08:00 DEBUG [2204:140650076162848] [trust_dns_resolver::name_server::name_server_pool] sending request: [Query { name: Name("dns.google"), query_type: A, query_class: IN }]
2022-10-01T16:48:03.502815266+08:00 DEBUG [2204:140650076162848] [trust_dns_resolver::name_server::name_server] reconnecting: NameServerConfig { socket_addr: 8.8.8.8:53, protocol: Udp, tls_dns_name: None, trust_nx_responses: false, bind_addr: None }
2022-10-01T16:48:03.502981923+08:00 DEBUG [2204:140650076162848] [trust_dns_proto::xfer] enqueueing message: [Query { name: Name("dns.google"), query_type: A, query_class: IN }]
2022-10-01T16:48:03.503107159+08:00 DEBUG [2204:140650076162848] [trust_dns_resolver::name_server::name_server] reconnecting: NameServerConfig { socket_addr: 8.8.4.4:53, protocol: Udp, tls_dns_name: None, trust_nx_responses: false, bind_addr: None }
2022-10-01T16:48:03.503267671+08:00 DEBUG [2204:140650076162848] [trust_dns_proto::xfer] enqueueing message: [Query { name: Name("dns.google"), query_type: A, query_class: IN }]
2022-10-01T16:48:03.503394346+08:00 DEBUG [2204:140650076162848] [trust_dns_proto::xfer::dns_handle] querying: dns.google AAAA
2022-10-01T16:48:03.503481485+08:00 DEBUG [2204:140650076162848] [trust_dns_resolver::name_server::name_server_pool] sending request: [Query { name: Name("dns.google"), query_type: AAAA, query_class: IN }]
2022-10-01T16:48:03.503610763+08:00 DEBUG [2204:140650076162848] [trust_dns_resolver::name_server::name_server] existing connection: NameServerConfig { socket_addr: 8.8.8.8:53, protocol: Udp, tls_dns_name: None, trust_nx_responses: false, bind_addr: None }
2022-10-01T16:48:03.503751956+08:00 DEBUG [2204:140650076162848] [trust_dns_proto::xfer] enqueueing message: [Query { name: Name("dns.google"), query_type: AAAA, query_class: IN }]
2022-10-01T16:48:03.503887520+08:00 DEBUG [2204:140650076162848] [trust_dns_resolver::name_server::name_server] existing connection: NameServerConfig { socket_addr: 8.8.4.4:53, protocol: Udp, tls_dns_name: None, trust_nx_responses: false, bind_addr: None }
2022-10-01T16:48:03.504017001+08:00 DEBUG [2204:140650076162848] [trust_dns_proto::xfer] enqueueing message: [Query { name: Name("dns.google"), query_type: AAAA, query_class: IN }]
2022-10-01T16:48:03.504323028+08:00 DEBUG [2204:140650076162848] [trust_dns_proto::udp::udp_stream] created socket successfully
2022-10-01T16:48:03.504437542+08:00 DEBUG [2204:140650076162848] [trust_dns_proto::udp::udp_stream] created socket successfully
2022-10-01T16:48:03.504533849+08:00 DEBUG [2204:140650076162848] [trust_dns_proto::udp::udp_stream] created socket successfully
2022-10-01T16:48:03.504589625+08:00 DEBUG [2204:140650076162848] [trust_dns_proto::udp::udp_stream] created socket successfully
2022-10-01T16:48:03.508290263+08:00 DEBUG [2204:140650076162848] [trust_dns_proto::udp::udp_client_stream] received message id: 47146
2022-10-01T16:48:03.508420854+08:00 DEBUG [2204:140650076162848] [trust_dns_resolver::error] Response:47146:RD,RA:NoError:2/0/0
2022-10-01T16:48:03.508520994+08:00 DEBUG [2204:140650076162848] [trust_dns_resolver::error] Response:47146:RD,RA:NoError:2/0/0
2022-10-01T16:48:03.508618362+08:00 DEBUG [2204:140650076162848] [trust_dns_proto::udp::udp_client_stream] received message id: 2421
2022-10-01T16:48:03.508686170+08:00 DEBUG [2204:140650076162848] [trust_dns_resolver::error] Response:2421:RD,RA:NoError:2/0/0
2022-10-01T16:48:03.508769733+08:00 DEBUG [2204:140650076162848] [trust_dns_resolver::error] Response:2421:RD,RA:NoError:2/0/0
2022-10-01T16:48:03.508861055+08:00 TRACE [2204:140650076162848] [shadowsocks::dns_resolver::resolver] DNS resolved dns.google:53 with trust-dns 0.006453116s
2022-10-01T16:48:03.508944629+08:00 TRACE [2204:140650076162848] [shadowsocks::net::tcp] trying connect dns.google:53 8.8.4.4:53
2022-10-01T16:48:03.511462352+08:00 TRACE [2204:140650076162848] [shadowsocks::net::tcp] connected dns.google:53 8.8.4.4:53
2022-10-01T16:48:03.511718158+08:00 DEBUG [2204:140650076162848] [shadowsocks_service::server::tcprelay] established tcp tunnel <local-client-ip>:40444 <-> dns.google:53 with ConnectOpts { fwmark: None, bind_local_addr: None, bind_interface: None, tcp: TcpSocketOpts { send_buffer_size: None, recv_buffer_size: None, nodelay: true, fastopen: true, keepalive: Some(300s) } }
2022-10-01T16:48:04.074705096+08:00 TRACE [2204:140650083496784] [shadowsocks::relay::tcprelay::crypto_io] generated AEAD cipher salt b"\\d\x0fw\xcb\x04\x11\xdf\x87G6\xc6X\xa1\xe7V"
2022-10-01T16:48:04.075222230+08:00 TRACE [2204:140650076162848] [shadowsocks::relay::tcprelay::aead_2022] got AEAD salt b"\xb8\x10TM5\xe6\xd8\n\x86\x15\n\xc3\xe7f\xa3F"
2022-10-01T16:48:04.075533888+08:00 TRACE [2204:140650076162848] [shadowsocks::relay::tcprelay::aead_2022] got AEAD header stream_type: 0, timestamp: 1664614083, length: 526, request_salt: None
2022-10-01T16:48:04.075622127+08:00 TRACE [2204:140650076162848] [shadowsocks_service::server::tcprelay] accepted tcp client connection <local-client-ip>:40456, establishing tunnel to 104.16.133.229:443
2022-10-01T16:48:04.077249915+08:00 DEBUG [2204:140650076162848] [shadowsocks_service::server::tcprelay] established tcp tunnel <local-client-ip>:40456 <-> 104.16.133.229:443 with ConnectOpts { fwmark: None, bind_local_addr: None, bind_interface: None, tcp: TcpSocketOpts { send_buffer_size: None, recv_buffer_size: None, nodelay: true, fastopen: true, keepalive: Some(300s) } }
2022-10-01T16:48:04.822602406+08:00 TRACE [2204:140650076162848] [shadowsocks_service::server::tcprelay] tcp tunnel <local-client-ip>:40456 <-> 104.16.133.229:443 closed, L2R 250 bytes, R2L 4315 bytes
2022-10-01T16:48:04.886068462+08:00 TRACE [2204:140650083496784] [shadowsocks::relay::tcprelay::crypto_io] generated AEAD cipher salt b"\xa3\xfb\"\xa4&\xe9Z\x08B\xab=\xec+\xf3\xedU"
2022-10-01T16:48:04.886446588+08:00 DEBUG [2204:140650076162848] [shadowsocks_service::server::tcprelay] tcp handshake failed, received EOF before a complete target Address, peer: <local-client-ip>:40458
2022-10-01T16:48:05.362445200+08:00 TRACE [2204:140650083496784] [shadowsocks::relay::tcprelay::crypto_io] generated AEAD cipher salt b"k\xc5\xd8\x13\xf5\xf41P\xf3\x0c\xb5!\xa3\xb4\xd7\xf0"
2022-10-01T16:48:05.362871741+08:00 TRACE [2204:140650076162848] [shadowsocks::relay::tcprelay::aead_2022] got AEAD salt b"M\xeb\xc4\xb5\xeex\x1e%\xd4\x1c\xd6\xcb\xd3Npc"
2022-10-01T16:48:05.363117744+08:00 TRACE [2204:140650076162848] [shadowsocks::relay::tcprelay::aead_2022] got AEAD header stream_type: 0, timestamp: 1664614084, length: 545, request_salt: None
2022-10-01T16:48:05.363225530+08:00 TRACE [2204:140650076162848] [shadowsocks_service::server::tcprelay] accepted tcp client connection <local-client-ip>:40464, establishing tunnel to 142.251.4.188:5228
2022-10-01T16:48:05.365389264+08:00 DEBUG [2204:140650076162848] [shadowsocks_service::server::tcprelay] established tcp tunnel <local-client-ip>:40464 <-> 142.251.4.188:5228 with ConnectOpts { fwmark: None, bind_local_addr: None, bind_interface: None, tcp: TcpSocketOpts { send_buffer_size: None, recv_buffer_size: None, nodelay: true, fastopen: true, keepalive: Some(300s) } }
2022-10-01T16:48:06.114950641+08:00 TRACE [2204:140650083496784] [shadowsocks::relay::tcprelay::crypto_io] generated AEAD cipher salt b"\xda\x89F\xb5,\x0e\xaeL\xd3|\x8a\\\t\xac\x01\xd7"
2022-10-01T16:48:06.115365948+08:00 TRACE [2204:140650076162848] [shadowsocks::relay::tcprelay::aead_2022] got AEAD salt b"jT\x93\x82Zy{\x99Ov\xd5BQ\x7f2\x1a"
2022-10-01T16:48:06.115588115+08:00 TRACE [2204:140650076162848] [shadowsocks::relay::tcprelay::aead_2022] got AEAD header stream_type: 0, timestamp: 1664614085, length: 530, request_salt: None
2022-10-01T16:48:06.115670306+08:00 TRACE [2204:140650076162848] [shadowsocks_service::server::tcprelay] accepted tcp client connection <local-client-ip>:40476, establishing tunnel to 104.16.133.229:443
2022-10-01T16:48:06.115818700+08:00 DEBUG [2204:140650076162848] [shadowsocks_service::server::tcprelay] established tcp tunnel <local-client-ip>:40476 <-> 104.16.133.229:443 with ConnectOpts { fwmark: None, bind_local_addr: None, bind_interface: None, tcp: TcpSocketOpts { send_buffer_size: None, recv_buffer_size: None, nodelay: true, fastopen: true, keepalive: Some(300s) } }
2022-10-01T16:48:06.874897370+08:00 TRACE [2204:140650076162848] [shadowsocks_service::server::tcprelay] tcp tunnel <local-client-ip>:40476 <-> 104.16.133.229:443 closed, L2R 250 bytes, R2L 1576 bytes
^C2022-10-01T16:48:53.596180513+08:00 INFO  [2204:140650083496784] [shadowsocks_rust::monitor::imp] received SIGINT, exiting

CC @madeye @zonyitoo @database64128

pexcn avatar Oct 01 '22 09:10 pexcn

Related: #888

You might be interested in shadowsocks-go's reject policy

database64128 avatar Oct 01 '22 10:10 database64128

You might be interested in shadowsocks-go's reject policy

@zonyitoo Rust 版可以实现此功能吗？

pexcn avatar Oct 01 '22 10:10 pexcn

Maybe you should experiment with different reject policies and post the results to make for a more convincing feature request. 😄

database64128 avatar Oct 01 '22 10:10 database64128

晚点测试一下😅

pexcn avatar Oct 01 '22 11:10 pexcn

You might be interested in shadowsocks-go's reject policy

@database64128 每一个选项都测试过，端口也一样会被临时屏蔽

pexcn avatar Oct 02 '22 06:10 pexcn

我开过阿里云国际的vps有遇到这个情况，新开的机器，也直接会遇到这个状况，不过用的加密方式是chacha20-ietf-poly1305 这种AEAD的，不是最新的2022的。

nasaboy avatar Oct 02 '22 11:10 nasaboy

我开过阿里云国际的vps有遇到这个情况，新开的机器，也直接会遇到这个状况，不过用的加密方式是chacha20-ietf-poly1305 这种AEAD的，不是最新的2022的。

我今天试了 chacha20-ietf-poly1305 和 aes-128-gcm, 也有这样的问题。但是就那一个 VPS 有这样的问题，其余正常

pexcn avatar Oct 02 '22 11:10 pexcn

我开过阿里云国际的vps有遇到这个情况，新开的机器，也直接会遇到这个状况，不过用的加密方式是chacha20-ietf-poly1305 这种AEAD的，不是最新的2022的。

我今天试了 chacha20-ietf-poly1305 和 aes-128-gcm, 也有这样的问题。但是就那一个 VPS 有这样的问题，其余正常

我猜测是ip段或者什么被重点监控了，应该是识别到了ss，具体和哪种加密方式没有关系，不过我没去折腾v2之类的，也无法验证，纯猜测，后面转去Amazon了，就正常，虽然偶尔会被gfw封ip。

nasaboy avatar Oct 02 '22 12:10 nasaboy

@nasaboy 我还测试了 mtg (tls 模式), 这个能正常使用。可能是（对某些 IP 段）识别不了的流量就会被屏蔽？

pexcn avatar Oct 02 '22 12:10 pexcn

@pexcn Well, that was not unexpected. https://github.com/shadowsocks/shadowsocks-org/issues/204#issuecomment-1266710067 should be the solution to your problem. It's not in any stable release yet so you have to build it yourself or grab the binaries from GitHub Actions.

database64128 avatar Oct 04 '22 10:10 database64128

我也遇到了此类问题 阿里云日本

zhao123gg avatar Oct 04 '22 16:10 zhao123gg

It's not in any stable release yet so you have to build it yourself or grab the binaries from GitHub Actions.

Update: A new release is out. @pexcn Are you interested in testing whether this feature works for you?

database64128 avatar Oct 16 '22 03:10 database64128

@database64128 我有空再试试😅

pexcn avatar Oct 16 '22 11:10 pexcn

新IP，搭了两天直接被封IP了

Greyh4t avatar Oct 25 '22 02:10 Greyh4t

Update: A new release is out. @pexcn Are you interested in testing whether this feature works for you?

刚刚测试了一下，不管有没有使用 unsafeRequestStreamPrefix 和 unsafeResponseStreamPrefix, 只要是使用 blake3 加密方式就能正常工作。

( shadowsocks-go v1.4.0 和 shadowsocks-rust v1.15.0-alpha.9 都能正常使用 )

pexcn avatar Oct 28 '22 14:10 pexcn

So the conclusion is that the GFW stopped interfering with your proxy traffic? 😄

database64128 avatar Oct 28 '22 14:10 database64128

So the conclusion is that the GFW stopped interfering with your proxy traffic? 😄

😂噢... 并不是，我刚刚又试了下，~~shadowsocks-rust 版本只能作为客户端使用，如果把它用作服务端，端口仍然会被屏蔽。而 shadowsocks-go 可以作为服务端。~~

UPDATE: 好像没测清楚。。不通的情况也许只是有丢包，我这两天再看看，有情况再反馈😅

我的配置是这样的：

root@SJCX ~/ss-go # cat server.json
{
    "servers": [
        {
            "name": "ss-2022",
            "listen": ":1778",
            "protocol": "2022-blake3-aes-128-gcm",
            "enableTCP": true,
            "listenerTFO": true,
            "enableUDP": true,
            "mtu": 1500,
            "psk": "************************"
        }
    ],
    "udpPreferIPv6": false
}

pexcn avatar Oct 28 '22 14:10 pexcn

There are no behavioral differences between shadowsocks-rust's TCP server and shadowsocks-go's TCP server (without custom reject policy or the unsafe features). I suggest you run 3 servers on 3 different ports:

  1. shadowsocks-rust
  2. shadowsocks-go (default)
  3. shadowsocks-go (unsafe stream prefix + unsafe fallback)

This should make testing easier and help you get more accurate results.

database64128 avatar Oct 28 '22 15:10 database64128

@database64128 刚刚又按照上述方法测了一下，开了三个端口，curl --socks5 127.0.0.1:1080 ip-api.com 一直都没问题的，但是用它浏览几个网页，端口就被屏蔽了，也许是流量大了。（三个端口都测了，均被屏蔽）

unsafe 那个特性我是直接用这里提供的参数，不知道配置有没有问题

{
    "servers": [
        {
            "name": "socks5",
            "listen": ":1080",
            "protocol": "socks5",
            "enableTCP": true,
            "listenerTFO": true,
            "enableUDP": true,
            "mtu": 1500
        }
    ],
    "clients": [
        {
            "name": "ss-2022-unsafe",
            "endpoint": "*********:****",
            "protocol": "2022-blake3-aes-128-gcm",
            "enableTCP": true,
            "dialerTFO": true,
            "enableUDP": true,
            "mtu": 1500,
            "psk": "**********************",
            "unsafeRequestStreamPrefix": "R0VUIC8gSFRUUC8xLjENCkhvc3Q6IGxvY2FsaG9zdA0KDQo=",
            "unsafeResponseStreamPrefix": "SFRUUC8xLjEgMjAwIE9LDQpDb25uZWN0aW9uOiBjbG9zZQ0KDQo="
        }
    ]
}

pexcn avatar Oct 28 '22 17:10 pexcn

What about combining unsafe stream prefix with unsafe fallback? And use the fallback domain as part of the prefix. For example, if the fallback address is example.com:80, change the Host header in the request prefix to example.com.

We might also need longer prefixes to further lower the entropy of the first TCP segment. Try something like:

printf 'GET / HTTP/1.1\r\nHost: example.com\r\n\r\n000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000' | base64
printf 'HTTP/1.1 200 OK\r\nConnection: close\r\n\r\n000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000' | base64

And the config will be like:

{
    "servers": [
        {
            "name": "socks5",
            "listen": ":1080",
            "protocol": "socks5",
            "enableTCP": true,
            "listenerTFO": true,
            "enableUDP": true,
            "mtu": 1500
        }
    ],
    "clients": [
        {
            "name": "ss-2022-unsafe",
            "endpoint": "*********:****",
            "protocol": "2022-blake3-aes-128-gcm",
            "enableTCP": true,
            "dialerTFO": true,
            "enableUDP": true,
            "mtu": 1500,
            "psk": "**********************",
            "unsafeFallbackAddress": "example.com:80",
            "unsafeRequestStreamPrefix": "R0VUIC8gSFRUUC8xLjENCkhvc3Q6IGV4YW1wbGUuY29tDQoNCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMA==",
            "unsafeResponseStreamPrefix": "SFRUUC8xLjEgMjAwIE9LDQpDb25uZWN0aW9uOiBjbG9zZQ0KDQowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA="
        }
    ]
}

On startup, both server and client will print the "unsafe ... feature taints the server/client" message.

database64128 avatar Oct 28 '22 18:10 database64128

我设置了 bing.com:80, 仍然会有这个问题。😥

详细的配置如下：

{
    "servers": [
        {
            "name": "ss-2022-unsafe",
            "listen": ":1778",
            "protocol": "2022-blake3-aes-128-gcm",
            "enableTCP": true,
            "listenerTFO": true,
            "enableUDP": true,
            "mtu": 1500,
            "psk": "*********************",
            "unsafeFallbackAddress": "bing.com:80",
            "unsafeRequestStreamPrefix": "R0VUIC8gSFRUUC8xLjENCkhvc3Q6IGJpbmcuY29tDQoNCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMA==",
            "unsafeResponseStreamPrefix": "SFRUUC8xLjEgMjAwIE9LDQpDb25uZWN0aW9uOiBjbG9zZQ0KDQowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA="
        }
    ],
    "udpPreferIPv6": false
}

pexcn avatar Oct 29 '22 08:10 pexcn

Thank you for bearing with me and keeping the experiment going! 😄

At this point it's still not clear what characteristics are triggering the blocking. gfw-report/shadowsocks-rust@d1cf917deebe1999044ca93965a602223de26be7 adjusts the 1/0 ratio if it's within (0.7, 1.4). Maybe our prefixes are still too short to be effective. Let's bump it up to 512 bytes and remove the fake HTTP header.

for _ in {0..511}; do printf '0'; done | base64 -w0

database64128 avatar Oct 29 '22 09:10 database64128

@database64128 仍然有这个问题。多次 curl --socks5 127.0.0.1:1080 ip-api.com 是有结果的，然而浏览器使用这个 socks5 端口进行网页访问的时候马上就不通了😵。

同时日志里出现：

2022-10-29T20:04:33.069+0800 WARN service/tcp.go:249 Two-way relay failed {"server": "socks5", "listenAddress": ":1080", "clientAddress": "[::ffff:192.168.1.100]:53158", "targetAddress": "github.com:443", "nl2r": 517, "nr2l": 0, "error": "read tcp 192.168.1.10:35648->**.**.**.**:****: read: connection reset by peer"}

我的配置的 unsafe 部分如下：

            "unsafeFallbackAddress": "bing.com:80",
            "unsafeRequestStreamPrefix": "MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA=",
            "unsafeResponseStreamPrefix": "MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA="

pexcn avatar Oct 29 '22 12:10 pexcn

This does not seem like how the GFW blocks things. Can you also check the corresponding server log message?

database64128 avatar Oct 29 '22 12:10 database64128

This does not seem like how the GFW blocks things. Can you also check the corresponding server log message?

服务端总共的日志只有这些：

root@SJCX ~/ss-go # cat ss.log
2022-10-29T20:02:12.561+0800 WARN service/server.go:95 Unsafe stream prefix taints the server {"name": "ss-2022-unsafe"}
2022-10-29T20:02:12.562+0800 WARN service/server.go:110 Unsafe fallback taints the server {"server": "ss-2022-unsafe", "fallbackAddress": "bing.com:80"}
2022-10-29T20:02:12.562+0800 INFO service/tcp.go:95 Started TCP relay service {"server": "ss-2022", "listenAddress": ":1777"}
2022-10-29T20:02:12.562+0800 INFO service/udp_session.go:146 Started UDP session relay service {"server": "ss-2022", "listenAddress": ":1777"}
2022-10-29T20:02:12.562+0800 INFO service/tcp.go:95 Started TCP relay service {"server": "ss-2022-unsafe", "listenAddress": ":1778"}
2022-10-29T20:02:12.562+0800 INFO service/udp_session.go:146 Started UDP session relay service {"server": "ss-2022-unsafe", "listenAddress": ":1778"}
2022-10-29T20:03:17.456+0800 INFO service/tcp.go:237 Two-way relay started {"server": "ss-2022-unsafe", "listenAddress": ":1778", "clientAddress": "[::ffff:**.**.**.**]:48688", "targetAddress": "208.95.112.1:80", "initialPayloadLength": 74}
2022-10-29T20:03:17.633+0800 INFO service/tcp.go:261 Two-way relay completed {"server": "ss-2022-unsafe", "listenAddress": ":1778", "clientAddress": "[::ffff:**.**.**.**]:48688", "targetAddress": "208.95.112.1:80", "nl2r": 74, "nr2l": 1367}
2022-10-29T20:03:20.002+0800 INFO service/tcp.go:237 Two-way relay started {"server": "ss-2022-unsafe", "listenAddress": ":1778", "clientAddress": "[::ffff:**.**.**.**]:48696", "targetAddress": "208.95.112.1:80", "initialPayloadLength": 74}
2022-10-29T20:03:20.202+0800 INFO service/tcp.go:261 Two-way relay completed {"server": "ss-2022-unsafe", "listenAddress": ":1778", "clientAddress": "[::ffff:**.**.**.**]:48696", "targetAddress": "208.95.112.1:80", "nl2r": 74, "nr2l": 1367}
2022-10-29T20:03:21.274+0800 INFO service/tcp.go:237 Two-way relay started {"server": "ss-2022-unsafe", "listenAddress": ":1778", "clientAddress": "[::ffff:**.**.**.**]:48706", "targetAddress": "208.95.112.1:80", "initialPayloadLength": 74}
2022-10-29T20:03:21.454+0800 INFO service/tcp.go:261 Two-way relay completed {"server": "ss-2022-unsafe", "listenAddress": ":1778", "clientAddress": "[::ffff:**.**.**.**]:48706", "targetAddress": "208.95.112.1:80", "nl2r": 74, "nr2l": 1367}
2022-10-29T20:03:22.002+0800 INFO service/tcp.go:237 Two-way relay started {"server": "ss-2022-unsafe", "listenAddress": ":1778", "clientAddress": "[::ffff:**.**.**.**]:46482", "targetAddress": "208.95.112.1:80", "initialPayloadLength": 74}
2022-10-29T20:03:22.179+0800 INFO service/tcp.go:261 Two-way relay completed {"server": "ss-2022-unsafe", "listenAddress": ":1778", "clientAddress": "[::ffff:**.**.**.**]:46482", "targetAddress": "208.95.112.1:80", "nl2r": 74, "nr2l": 1367}
2022-10-29T20:03:23.170+0800 INFO service/tcp.go:237 Two-way relay started {"server": "ss-2022-unsafe", "listenAddress": ":1778", "clientAddress": "[::ffff:**.**.**.**]:46486", "targetAddress": "208.95.112.1:80", "initialPayloadLength": 74}
2022-10-29T20:03:23.351+0800 INFO service/tcp.go:261 Two-way relay completed {"server": "ss-2022-unsafe", "listenAddress": ":1778", "clientAddress": "[::ffff:**.**.**.**]:46486", "targetAddress": "208.95.112.1:80", "nl2r": 74, "nr2l": 1367}
2022-10-29T20:03:23.871+0800 INFO service/tcp.go:237 Two-way relay started {"server": "ss-2022-unsafe", "listenAddress": ":1778", "clientAddress": "[::ffff:**.**.**.**]:46490", "targetAddress": "208.95.112.1:80", "initialPayloadLength": 74}
2022-10-29T20:03:24.054+0800 INFO service/tcp.go:261 Two-way relay completed {"server": "ss-2022-unsafe", "listenAddress": ":1778", "clientAddress": "[::ffff:**.**.**.**]:46490", "targetAddress": "208.95.112.1:80", "nl2r": 74, "nr2l": 1367}
2022-10-29T20:03:24.526+0800 INFO service/tcp.go:237 Two-way relay started {"server": "ss-2022-unsafe", "listenAddress": ":1778", "clientAddress": "[::ffff:**.**.**.**]:46500", "targetAddress": "208.95.112.1:80", "initialPayloadLength": 74}
2022-10-29T20:03:24.711+0800 INFO service/tcp.go:261 Two-way relay completed {"server": "ss-2022-unsafe", "listenAddress": ":1778", "clientAddress": "[::ffff:**.**.**.**]:46500", "targetAddress": "208.95.112.1:80", "nl2r": 74, "nr2l": 1367}
2022-10-29T20:03:25.436+0800 INFO service/tcp.go:237 Two-way relay started {"server": "ss-2022-unsafe", "listenAddress": ":1778", "clientAddress": "[::ffff:**.**.**.**]:46504", "targetAddress": "208.95.112.1:80", "initialPayloadLength": 74}
2022-10-29T20:03:25.621+0800 INFO service/tcp.go:261 Two-way relay completed {"server": "ss-2022-unsafe", "listenAddress": ":1778", "clientAddress": "[::ffff:**.**.**.**]:46504", "targetAddress": "208.95.112.1:80", "nl2r": 74, "nr2l": 1367}
root@SJCX ~/ss-go #

pexcn avatar Oct 29 '22 12:10 pexcn

I found a Vultr server in the same situation as yours, and experimented with it. A few things I've found out about so far:

  1. This type of blocking only lasts around 3 minutes.
  2. Without unsafe prefixes, just a few TCP connections will trigger the blocking almost immediately.
  3. With unsafe prefixes (fake HTTP headers or the all zeros/ones), there will be 3 blocking/unblocking cycles, after which there won't be any further interference.

The key seems to be surviving the 3 blocking/unblocking cycles. You'll observe that the proxy works for 3 minutes, then gets blocked for 3 minutes, then gets unblocked for another 3 minutes... It keeps going until the third time it's unblocked.

database64128 avatar Oct 29 '22 17:10 database64128

这个和我之前开阿里云国际的机器结果一样，开启server只要一连服务器，就会被封3分钟，3分钟后会解封，然后连了又继续封，我当时的宽带是移动的，我以为是移动的问题，后来新开了服务器，用联通4G也测试到了一样的情况，换加密方式也没用，所以我当时得出的结论是要不网段被特殊照顾了或者ss协议被识别了。

nasaboy avatar Oct 30 '22 01:10 nasaboy

我这个是 virmach 的 vps, 差不多也是这种情况😂

pexcn avatar Oct 30 '22 03:10 pexcn

ipv6 please

chuxi avatar Mar 07 '23 03:03 chuxi