You run a Telegram bot through OpenClaw on your own Linux server. One day it goes quiet. The bot can't send or receive. But the server itself is fine — SSH works, apt works, other sites load.
The reason: your server can't reach api.telegram.org. Some networks block or throttle it, so every call times out while everything else is fine.
The clean fix: route only OpenClaw's Telegram traffic through Cloudflare WARP (1.1.1.1). Everything else on the box stays direct and fast — including your SSH login.
Here is the full setup, step by step.
First, confirm it's a Telegram-only problem
curl --max-time 8 https://api.telegram.org/ # hangs / times out
curl --max-time 8 https://www.google.com/ # works instantly
If Telegram times out but other sites are quick, this guide is for you.
How it works
We chain three small tools:
OpenClaw ──▶ iptables ──▶ redsocks ──▶ WARP (SOCKS5) ──▶ Cloudflare ──▶ api.telegram.org
- WARP gives us a local proxy that exits through Cloudflare's network (which can reach Telegram).
- redsocks turns normal connections into proxy connections (so the app needs no proxy support — OpenClaw has none).
- iptables picks only OpenClaw's Telegram traffic and sends it to redsocks.
The trick is in that last step. We match by the app's user and Telegram's IP ranges, so nothing else is touched.
Step 1: Install WARP in proxy mode
# Add Cloudflare's package repo
curl -fsSL https://pkg.cloudflareclient.com/pubkey.gpg \
| gpg --yes --dearmor -o /usr/share/keyrings/cloudflare-warp-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/cloudflare-warp-archive-keyring.gpg] \
https://pkg.cloudflareclient.com/ $(lsb_release -cs) main" \
> /etc/apt/sources.list.d/cloudflare-client.list
apt-get update && apt-get install -y cloudflare-warp
# Sign up (free) and switch to proxy mode
warp-cli --accept-tos registration new
warp-cli --accept-tos mode proxy # opens a SOCKS5 proxy on 127.0.0.1:40000
warp-cli --accept-tos connect
Now check that WARP can reach Telegram:
curl --socks5-hostname 127.0.0.1:40000 https://api.telegram.org/
If that works while a plain curl still times out, WARP is your bypass.
Step 2: Install redsocks
WARP gives a SOCKS proxy, but OpenClaw doesn't speak SOCKS. redsocks bridges that gap.
apt-get install -y redsocks
# Our own config + service (avoids clashing with the package's default one)
cat > /etc/redsocks-warp.conf <<'EOF'
base { log = "stderr"; daemon = off; redirector = iptables; }
redsocks { local_ip = 127.0.0.1; local_port = 12345; ip = 127.0.0.1; port = 40000; type = socks5; }
EOF
cat > /etc/systemd/system/redsocks-warp.service <<EOF
[Unit]
After=warp-svc.service
Wants=warp-svc.service
[Service]
ExecStart=$(command -v redsocks) -c /etc/redsocks-warp.conf
Restart=always
[Install]
WantedBy=multi-user.target
EOF
# The package ships its own redsocks on the same port — turn it off
systemctl disable --now redsocks 2>/dev/null; systemctl mask redsocks
systemctl daemon-reload && systemctl enable --now redsocks-warp
redsocks now listens on 127.0.0.1:12345 and forwards to WARP.
Step 3: Redirect only OpenClaw's Telegram traffic
This is the safe part. We send to redsocks only:
- traffic from the
openclawuser, and - traffic going to Telegram's IP ranges.
SSH, system updates, and your other apps are never touched.
iptables -t nat -N TGWARP
iptables -t nat -A TGWARP -p tcp -j REDIRECT --to-ports 12345
# Telegram's published IP ranges
for net in 149.154.160.0/20 91.108.4.0/22 91.108.8.0/22 91.108.56.0/22 95.161.64.0/20; do
iptables -t nat -A OUTPUT -m owner --uid-owner openclaw -p tcp -d "$net" -j TGWARP
done
Because the rule is tied to the openclaw user, WARP's own traffic (it runs as root) is not caught — so there is no loop.
Step 4: Pin api.telegram.org to IPv4
api.telegram.org also has an IPv6 address. If OpenClaw picks IPv6, it skips our IPv4 rule. Pin it to IPv4 so it always uses the path we redirect:
echo "149.154.167.220 api.telegram.org" >> /etc/hosts
Step 5: Restart OpenClaw and test
systemctl restart openclaw
sudo -u openclaw curl -s https://api.telegram.org/bot<YOUR_TOKEN>/getMe
You should get back {"ok":true,...} with your bot's details. Your bot is alive again.
Make it survive reboots
Services started with systemctl enable come back on their own. Save the iptables rule in a tiny boot script so it returns too:
cat > /usr/local/sbin/tg-warp-iptables.sh <<'EOF'
#!/bin/bash
iptables -t nat -N TGWARP 2>/dev/null
iptables -t nat -F TGWARP
iptables -t nat -A TGWARP -p tcp -j REDIRECT --to-ports 12345
for net in 149.154.160.0/20 91.108.4.0/22 91.108.8.0/22 91.108.56.0/22 95.161.64.0/20; do
iptables -t nat -C OUTPUT -m owner --uid-owner openclaw -p tcp -d "$net" -j TGWARP 2>/dev/null \
|| iptables -t nat -A OUTPUT -m owner --uid-owner openclaw -p tcp -d "$net" -j TGWARP
done
EOF
chmod +x /usr/local/sbin/tg-warp-iptables.sh
# run it from a oneshot systemd unit on boot (After=redsocks-warp.service)
How to undo it later
When your network can reach Telegram directly again:
systemctl disable --now redsocks-warp
iptables -t nat -F TGWARP
sed -i '/api.telegram.org/d' /etc/hosts
systemctl restart openclaw
Why this design is safe
- Scoped by user + IP — only OpenClaw, only Telegram. Nothing else changes route.
- SSH stays direct — no risk of locking yourself out of the server.
- No app changes — OpenClaw doesn't even know a proxy exists.
- Reversible — a few commands put everything back.
That's the whole trick: WARP for the exit, redsocks for the bridge, and one small iptables rule to keep it tight. Your Telegram bot keeps running, no matter what the local network does.