YES. Exactly. It is what I have said above. A large number of connections > 90.
All these connections are super busy.
Ok… sounds like your network needs more capacity?
Upgrade your ziti to v1.6.7 when it comes out and try enabling the “super network” flag in zrok. That will separate the control plane from the data plane and might improve performance. But ultimately, we’re limited by the compute and bandwidth that’s available. An overlay network, by design, is going to impose some amount of performance penalty.
I see that 1 connection is enough.
curl --proxy http://127.0.0.1:port -o /dev/null https://sbg.proof.ovh.net/files/10Gb.dat
So my parallel curl takes up to 12 seconds
curl --proxy http://127.0.0.1:port -s -w '%{time_total}s' -o /dev/null http://www.google.com
13.482587s
There is no problem with network.
The share (tcptunnel) is on 500Mbs network.
A parallel curl without proxy work fast:
curl -s -w '%{time_total}s' -o /dev/null http://www.google.com
0.090997s
curl --proxy http://127.0.0.1:port -s -w '%{time_total}s' -o /dev/null http://www.google.com
8.180164s
curl -s -w '%{time_total}s' -o /dev/null http://www.google.com
0.085028s
This is the configuration:
People run apt upgrade on their pc, miles away from me.
I run curl at home.
The share (tcptunnel) is on a dedicated host with a 500Mbps network.
On one side:
zrok share (tcptunnel) has a very good network 500Mbps.
On another side:
The user does apt upgrade using a mobile network (284kB/s)
My home network is about 20Mbps.
I have just tried a similar scenario:
I Configuration: tcpTunnel
Host1 (500Mbps)
zrok share private -b tcpTunnel 127.0.0.1:port --headless --open
[ 1.029] INFO sdk-golang/ziti.(*listenerManager).createSessionWithBackoff: {session token=[dd372a1b-6cf0-4287-9d1e-77b303f22f43]} new service session
[ 1.235] INFO main.(*sharePrivateCommand).shareLocal: allow other to access your share with the following command:
zrok access private yontuncx87d6
[ 1.235] INFO zrok/endpoints/tcpTunnel.(*Backend).Run: started
Host2 (100Mbps)
zrok access private yontuncx87d6 -b 127.0.0.1:7777 --headless
[ 0.904] INFO main.(*accessPrivateCommand).accessLocal: access the zrok share at the following endpoint: tcp://127.0.0.1:7777
Host3 (20Mbps)
zrok access private yontuncx87d6 -b 127.0.0.1:7777 --headless
II We validate the setup.
Host2 (100Mbps)
curl --proxy http://127.0.0.1:7777 -s -w '%{time_total}s' -o /dev/null https://www.google.com
0.241377s
Host3 (20Mbps)
curl --proxy http://127.0.0.1:7777 -s -w '%{time_total}s' -o /dev/null https://www.google.com
0.248842s
III We run the test.
Host3 (20Mbps): downloading at 2237kB/s
curl --proxy http://127.0.0.1:7777 -o /dev/null https://sbg.proof.ovh.net/files/10Gb.dat
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 10.0G 0 36.6M 0 0 2225k 0 1:18:30 0:00:16 1:18:14 2237k
Host2 (100Mbps): http request
curl --proxy http://127.0.0.1:7777 -s -w '%{time_total}s' -o /dev/null https://www.google.com
16.366836s
curl --proxy http://127.0.0.1:7777 -s -w '%{time_total}s' -o /dev/null https://www.google.com
16.962323s
curl --proxy http://127.0.0.1:7777 -s -w '%{time_total}s' -o /dev/null https://www.google.com
15.521564s
After we have stopped the download (at a very low speed 2MB/s) on Host3 we repeat the curl on Host2
Host2 (100Mbps): http request
curl --proxy http://127.0.0.1:7777 -s -w '%{time_total}s' -o /dev/null https://www.google.com
0.238639s
It seems that we have the same problem with socks shares.
I Configuration: socks
Host1 (500Mbps)
zrok share private -b socks --headless --open
[ 1.043] INFO sdk-golang/ziti.(*listenerManager).createSessionWithBackoff: {session token=[d56f711f-7077-4a60-872f-e4cd2be27bf8]} new service session
[ 1.182] INFO main.(*sharePrivateCommand).shareLocal: allow other to access your share with the following command:
zrok access private q2y67021wywn
Host2 (100Mbps)
zrok access private q2y67021wywn -b 127.0.0.1:9999 --headless
Host3 (20Mbps)
zrok access private q2y67021wywn -b 127.0.0.1:9999 --headless
II We validate the configuration.
Host2 (100Mbps)
curl --proxy socks5://127.0.0.1:9999 -s -w '%{time_total}s' -o /dev/null https://www.google.com
0.322686s
Host3 (20Mbps)
curl --proxy socks5://127.0.0.1:9999 -s -w '%{time_total}s' -o /dev/null https://www.google.com
0.303178s
III We run the test.
Host3 (20Mbps): downloading at 2512kB/s
curl --proxy socks5://127.0.0.1:9999 -o /dev/null https://mirror.in2p3.fr/pub/fedora/linux/releases/42/Workstation/x86_64/iso/Fedora-Workstation-Live-42-1.1.x86_64.iso
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
2 2287M 2 61.0M 0 0 2488k 0 0:15:41 0:00:25 0:15:16 2512k
Host2 (100Mbps): http request
curl --proxy socks5://127.0.0.1:9999 -s -w '%{time_total}s' -o /dev/null https://www.google.com
17.690794s
curl --proxy socks5://127.0.0.1:9999 -s -w '%{time_total}s' -o /dev/null https://www.google.com
19.403398s
curl --proxy socks5://127.0.0.1:9999 -s -w '%{time_total}s' -o /dev/null https://www.google.com
21.163678s
IV Conclusion
While downloading from Host3 at a very low speed 2MB/s we obtain on Host2 having 100Mbps network connection the execution time about 20 seconds.
The last available stable version is openziti 1.5.4
{
"chSeq": 43500,
"circuitId": "plmsS14-c",
"connId": 188,
"edgeSeq": 0,
"error": "timeout waiting to put message in send queue: context deadline exceeded",
"file": "github.com/openziti/ziti/router/xgress_edge/listener.go:725",
"func": "github.com/openziti/ziti/router/xgress_edge.(*edgeClientConn).sendStateConnectedReply",
"level": "error",
"msg": "failed to send state response",
"time": "2025-08-19T11:27:57.858Z",
"type": "EdgeStateConnectedType"
}
Probably this is an example of the situation you were talking about above.
On the other hand in my tests the network bandwidth is much higher and the same result you will obtain even on a local interface. You could enable an environment local to the service. And with this local environment you will face the same problem accessing the local service (socks for simplicity).
In my test: one host is slowly downloding (2MB/s) and another one (with 100Mbps network, or even a local environment) tries to run curl.
I don’t know: It could happen that the buffers are filled up with data that the slowing downloading client has no time to consume. So the service works in a single client mode.
zrok version 1.1.2
zrok config set superNetwork true
systemctl --user restart zrok-agent.service
curl --proxy http://127.0.0.1:port -o /dev/null https://mirror.in2p3.fr/pub/fedora/linux/releases/42/Workstation/x86_64/iso/Fedora-Workstation-Live-42-1.1.x86_64.iso
curl --proxy http://127.0.0.1:port -s -w '%{time_total}s' -o /dev/null https://www.google.com
15.713272s
It seems that superNetwork true does not change anything.
Are you running that against routers with a minimum version or 1.6.7? The performance optimizations require support on both the SDK and router side.
- I have installed the ziti 1.6.7 on the host running the service. However ziti-controller is still 1.5.4. The routers are local to the service. I have 6 routers on the same host because the host has 6 ipv4 and one ipv6.
- I have enabled superNetwork on the both sides: for the service and agent environments.
- I have restarted zrok socks service (zrok 1.1.2)
- I run the test.