DEV Community

Cover image for Use the Telegram Bot API in OpenClaw via Cloudflare WARP (1.1.1.1)
Abhay
Abhay

Posted on

Use the Telegram Bot API in OpenClaw via Cloudflare WARP (1.1.1.1)

#telegram #linux #devops #cloudflarechallenge

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode
  • 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
Enter fullscreen mode Exit fullscreen mode

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/
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Step 5: Restart OpenClaw and test 

systemctl restart openclaw
sudo -u openclaw curl -s https://api.telegram.org/bot<YOUR_TOKEN>/getMe
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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

[Service]
ExecStartPost=/usr/bin/warp-cli --accept-tos connect
Enter fullscreen mode Exit fullscreen mode

Then apply it:

systemctl restart warp-svc
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (0)