naiveproxy client "HTTP2_SESSION_STALLED_MAX_STREAMS" log

[CyberLeopard]

Hi,

Server: Caddy v2 with naïve fork of forwardproxy (latest) Client: naiveproxy in redir mode (latest)

Multiple endpoints are using this client. After some time can't open web pages and naiveproxy logging a lot like these below:

[0428/022221.104691:INFO:naive_connection.cc(250)] Connection 17146 to X.X.X.X:443 [0428/022221.104847:INFO:naive_proxy_bin.cc(382)] HTTP2_SESSION(14546): HTTP2_SESSION_STALLED_MAX_STREAMS: PHASE_NONE: {"params":{"max_concurrent_streams":250,"num_active_st reams":250,"num_created_streams":0,"num_pushed_streams":0,"url":"https://X.X.X.X/"},"phase":0,"source":{"id":14546,"start_time":"4514461","type":9},"time":"12648906"," type":214}

What's the best setup to allow multiple endpoints to access one single naiveproxy client instance concurrently?

Thanks.

[klzgrad]

The limit of 250 is from here https://github.com/golang/net/blob/85d9c07bbe3a33a875ef21b02f48ac405ad17d5f/http2/server.go#L58 also https://source.chromium.org/chromium/chromium/src/+/master:net/spdy/spdy_session.cc;l=494;drc=221e331b49dfefadbc6fa40b0c68e6f97606d0b3

1. Turn on an ad blocker so they use less connections.
2. Create several instances of naiveproxy as backends and use a HAProxy to load balance
3. Try one naiveproxy instance with --concurrency=4 and see if it improves

[CyberLeopard]

Hi, thank you so much for your answer.

I try to setup Haproxy (TCP mode) infront of Naiveproxy client (redir mode), use iptables to redirect TCP to Haproxy and load banlance to Naiveproxy instances. Web access failed with errors like below:

[0429/112144.582564:INFO:naive_connection.cc(250)] Connection 5242 to 127.0.0.1:1081 [0429/112144.646967:INFO:naive_proxy.cc(178)] Connection 5242 closed: OK [0429/112144.987133:INFO:naive_connection.cc(250)] Connection 5243 to 127.0.0.1:1081 [0429/112145.038705:INFO:naive_proxy.cc(178)] Connection 5243 closed: OK [0429/112145.066715:INFO:naive_connection.cc(250)] Connection 5244 to 127.0.0.1:1081 [0429/112145.130917:INFO:naive_proxy.cc(178)] Connection 5244 closed: OK

I try to set load-balance use iptables directly, that works but I can't find an easy way to do failover. Suppose one instance of Naiveproxy crashed, that'll cause great network failure.

iptables -t nat -A NAIVE -p tcp -j REDIRECT --to-ports 1081 -m statistic --mode nth --every 2 --packet 0
iptables -t nat -A NAIVE -p tcp -j REDIRECT --to-ports 1082

[klzgrad]

Have you tried the concurrency option? It could work.

With Haproxy it is implied that you would need Haproxy in redir or tproxy mode so to capture the destination address and relay that information to naiveproxy in socks5.

[lxhao61]

Have you tried the concurrency option? It could work.

With Haproxy it is implied that you would need Haproxy in redir or tproxy mode so to capture the destination address and relay that information to naiveproxy in socks5.

It can be achieved by adding caddy-l4 plug-in, without adding Haproxy.

[CyberLeopard]

Have you tried the concurrency option? It could work.

With Haproxy it is implied that you would need Haproxy in redir or tproxy mode so to capture the destination address and relay that information to naiveproxy in socks5.

I have tested 1 naiveproxy instance with "concurrent = 4", it can hold longer but the error came out eventually.

[klzgrad]

I still recommend Haproxy with TPROXY, https://www.haproxy.com/blog/howto-transparent-proxying-and-binding-with-haproxy-and-aloha-load-balancer/.

Naive is not designed as a load balancing proxy server for massive parallelism, and does not try to be one. Haproxy is better at load balancing strategies given limited underlying camouflage h2 connections. I think you should combine them for your use case. Haproxy with balance first and fullconn.

[klzgrad]

HTTP2_SESSION_STALLED_MAX_STREAMS is no longer logged without --v option, which could clog the terminal.

It is possible to dynamically scale up the number of tunnel connections depending on the number of used streams, but this is a relative rare use case and more thoughts are needed on how it should be implemented. The main concern is even if it can scale up to multiple users, it would have issues scaling up to like hundreds of users, so the intended scale would be a major consideration.