TL;DR — Route only your bot's Telegram traffic through Cloudflare WARP using redsocks + one scoped iptables rule. SSH and everything else stay direct. Tested on Ubuntu 24.04 (Debian-based).

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

On older warp-cli builds the first command is warp-cli register instead of warp-cli registration new.

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 openclaw user, 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 on every boot with a oneshot unit
cat > /etc/systemd/system/tg-warp-iptables.service <<'EOF'
[Unit]
After=redsocks-warp.service
Wants=redsocks-warp.service
[Service]
Type=oneshot
ExecStart=/usr/local/sbin/tg-warp-iptables.sh
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
EOF
systemctl daemon-reload && systemctl enable tg-warp-iptables

One more thing: WARP starts on boot via warp-svc, but it doesn't always reconnect by itself. Make it sure. Run:

systemctl edit warp-svc

An editor opens. Add exactly these lines, then save and exit:

[Service]
ExecStartPost=/usr/bin/warp-cli --accept-tos connect

Then apply it:

systemctl restart warp-svc

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.