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

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 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 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.