I’m having a major Docker issue on ZimaOS( v 1.5.4 alpha 2) where pulling images fails everywhere except the ZimaOS UI. From the terminal, docker pull always fails with net/http: TLS handshake timeout, even though the host has internet access and HTTPS works. I also tried deploying stacks using Docker Compose through Portainer and Arcane, and they fail as well with image pull errors. I checked system time and NTP (both synced), verified DNS via /etc/resolv.conf, tested connectivity to Docker Hub with curl, restarted Docker, and tried forcing DNS and disabling IPv6 in the Docker daemon, but nothing helped. This makes it impossible to deploy containers normally unless images are pulled through the UI first. Has anyone face this issue ?
That’s a very unusual one, Docker pulls fail everywhere (CLI / Portainer / Arcane) with:
net/http: TLS handshake timeout
but pulling via the ZimaOS UI works.
That strongly suggests it’s not general internet / DNS / time sync, but something specific to the Docker engine network path (common causes: MTU issue, IPv6 routing issues, or an alpha regression in 1.5.4-a2).
Quick isolation tests (2 mins)
Run these:
curl -Iv https://registry-1.docker.io/v2/ 2>&1 | head -30
docker run --rm curlimages/curl -Iv https://registry-1.docker.io/v2/ 2>&1 | head -30
- If the first works but the second fails > Docker bridge/NAT path issue (MTU/IPv6).
- If both work but docker pull fails > docker daemon/client issue.
Most common fix: MTU + IPv6
Try forcing Docker config:
sudo nano /etc/docker/daemon.json
Paste:
{
"mtu": 1500,
"ipv6": false,
"dns": ["1.1.1.1", "8.8.8.8"]
}
Restart Docker:
sudo systemctl restart docker
docker pull hello-world
If this only happens on 1.5.4 alpha2, I’d also recommend testing 1.5.3 stable to confirm it’s an alpha network regression.
If you want, paste the output of the 2 test commands above and we can narrow it down quickly.
hello!
i ve tested the 2 commands and here is the result :
curlfrom the host works and completes the TLS handshake with Docker Hub.- The same request from inside a Docker container fails with
net/http: TLS handshake timeout
I tried the usual fix (force MTU 1500, disable IPv6, set DNS to 1.1.1.1 / 8.8.8.8) and restarted Docker, but docker pull still fails with the same error.
i will install 1.5.3 stable and check if it work .
Perfect testing by @lou4y, this result is super clear
Here’s the key takeaway from your screenshots:
curlfrom the host OS completes TLS handshake to Docker Hub- Docker engine traffic (image pulls / container network) fails with
net/http: TLS handshake timeout - And even after forcing MTU 1500 + IPv6 off + DNS change, it still fails
So this is NOT “no internet”, and it’s NOT time/NTP/DNS.
This points strongly to a Docker network path issue inside ZimaOS (bridge/NAT/proxy/iptables), and very likely a 1.5.4 alpha2 regression.
Also note this line:
WARNING: Error loading config file: open /DATA/.docker/config.json: permission denied
That warning is probably unrelated to the TLS timeout, but it’s worth fixing later (docker is trying to read a user docker config from /DATA but doesn’t have permission).
Next best move
Installing/testing 1.5.3 stable is exactly the right call.
If 1.5.3 works normally, then we can confidently say:
“Confirmed bug/regression in 1.5.4 alpha2 affecting Docker image pulls outside the UI.”
That would be a good one to report to IceWhale with your screenshots + the 2 command outputs
hello again !
i have installed zima os 1.5.3 and tested again but still same result :
Anything i should try next , or just install a fresh os and try again.
Thanks for confirming. Since host HTTPS works but Docker pulls fail, this points strongly to a Docker bridge/NAT or IPv6 routing issue.
Don’t stress about the commands below — they’re safe.
Most are read-only (they only show info). The IPv6 step is a temporary test only (it resets on reboot, and can be undone instantly).
Please run these and paste the output:
ip link show docker0
ip route
getent ahosts registry-1.docker.io | head -20
sudo sysctl net.ipv4.ip_forward
sudo iptables -t nat -S | head -80
sudo journalctl -u docker --no-pager -n 120
env | grep -i proxy
Quick IPv6 isolation test (temporary):
sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1
docker pull hello-world
If Docker pull works after IPv6 disable → IPv6 routing is the issue.
If ip_forward is off or NAT rules are missing → Docker containers can’t reach the internet.
To undo IPv6 change immediately (optional):
sudo sysctl -w net.ipv6.conf.all.disable_ipv6=0
sudo sysctl -w net.ipv6.conf.default.disable_ipv6=0
Thanks a lot for the fast response. i tried these commands and that fixed the issue it seem the ipv6 was the problem all along, even after i installed a frech os the issue persisted but with it disabled i can pull images again .
here is another test :
is there a command to make the changes persist after reboot ?
Amazing result @lou4y — that confirms it 100%: broken IPv6 routing was causing the Docker TLS handshake timeout.
Explanation: IPv6 is enabled on the system, but the ISP/router/network isn’t routing IPv6 correctly end-to-end. Docker often tries IPv6 first, so the connection stalls during the TLS handshake and image pulls fail.
To make the IPv6 disable persistent after reboot:
sudo nano /etc/sysctl.d/99-disable-ipv6.conf
Paste:
net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1
net.ipv6.conf.lo.disable_ipv6=1
Apply immediately:
sudo sysctl --system
After reboot you can confirm:
cat /proc/sys/net/ipv6/conf/all/disable_ipv6
If it prints 1, it’s persistent 
Why Docker fails while the internet still works: browsers and many tools fall back to IPv4 very quickly, so normal HTTPS looks fine. Docker pulls involve multiple registry/auth TLS connections and can hit IPv6 first, so “half-working IPv6” shows up as net/http: TLS handshake timeout.
2 Likes
Thank you so much for your help! I really appreciate you taking the time to guide me through this fix.
1 Like