标签：#cloudflare

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-

I run a content site, do-and-coffee.com . Like everyone else, it gets scraped by AI crawlers. Instead of blocking them, I did something else: I put a paywall in front of the site that returns HTTP 402 Payment Required to bots, with machine-readable payment instructions. If a crawler pays a cent in USDC, it gets the article. If it doesn't, it gets the 402 and nothing else. Then I let it run for 30 days and watched. Here's what actually happened — and it's not the number you'd put on a pitch deck. TL;DR A Cloudflare Worker sits in front of the site. AI crawlers get 402 + x402 payment requirements ; humans and search bots pass through free. Payment is USDC on Base , $0.01 per article, verified and settled through Coinbase's CDP facilitator. 30-day result: 5,811 crawler requests, 5 paid, 5,806 served a 402. Revenue at $0.01/article ≈ $0.05 . The interesting part isn't the revenue. It's who paid: GPTBot paid 4 times out of 48 requests; ClaudeBot paid once out of 651. Architecture do-and-coffee.com/blog/article/* ─▶ x402 Worker (Cloudflare) │ has X-PAYMENT-RESPONSE? ───────────┤─▶ yes ─▶ proxy origin (200) KV cache hit (payer:url)? ─────────┤─▶ yes ─▶ proxy origin (200) no X-PAYMENT? ─────────────────────┤─▶ 402 + payment requirements has X-PAYMENT? ────────────────────┘ │ ├─▶ CDP /verify (is the signed payment valid?) ├─▶ CDP /settle (waitUntil: confirmed — on-chain) └─▶ on success: KV.put(payer:url, receipt, ttl 24h) ─▶ proxy origin The worker speaks the x402 protocol: a 402 response carries an accepts array describing exactly how to pay (scheme exact , network base , asset USDC, amount, payTo wallet). A compliant agent reads that, signs a USDC payment, and retries with an X-PAYMENT header. The worker verifies and settles it through Coinbase's facilitator, then proxies the real article. How it works The 402 response When there's no payment, the worker builds the requirements and returns 402: function buildPaymentRequirements ( resourceUrl : string , env : Env ): Payment

When I built whatsmy.fyi , I assumed I'd need a geolocation provider: MaxMind, ipinfo, ip-api, pick your poison. They all mean the same thing: an external dependency, an API key, a quota, added latency, and someone else's server seeing your users' IPs. Then I found out Cloudflare Workers makes the whole category unnecessary. The cf object Every request that hits a Cloudflare Worker carries a request.cf object, populated at the edge before your code even runs. No lookup, no latency, no key. Here's what's inside: { asn : 34984 , // ISP's autonomous system number asOrganization : " Superonline " , // ISP name city : " Istanbul " , region : " Istanbul " , country : " TR " , continent : " AS " , isEUCountry : undefined , // "1" if EU, undefined otherwise latitude : " 41.01380 " , // string, not number! longitude : " 28.94970 " , postalCode : " 34000 " , timezone : " Europe/Istanbul " , colo : " IST " , // which CF datacenter handled this clientTcpRtt : 12 , // user's RTT to the edge, in ms httpProtocol : " HTTP/3 " , tlsVersion : " TLSv1.3 " , tlsCipher : " AEAD-AES128-GCM-SHA256 " } That last group surprised me most: you get the user's HTTP protocol, TLS version, and actual TCP round-trip time for free. Try getting that from a geo API. A complete IP endpoint in ~30 lines export default { async fetch ( request ) { const cf = request . cf ?? {}; const ip = request . headers . get ( " CF-Connecting-IP " ); return Response . json ({ ip , city : cf . city ?? null , country : cf . country ?? null , isp : cf . asOrganization ?? null , asn : cf . asn ?? null , timezone : cf . timezone ?? null , lat : cf . latitude ? parseFloat ( cf . latitude ) : null , lng : cf . longitude ? parseFloat ( cf . longitude ) : null , protocol : cf . httpProtocol ?? null , tls : cf . tlsVersion ?? null , rttMs : cf . clientTcpRtt ?? null , }); }, }; That's the entire backend. No database, no GeoIP file to update monthly, no vendor. The gotchas (learned the hard way) 1. Coordinates are strings. lati

Building a "paste a YouTube link, get a transcript" feature sounds trivial until you deploy it to a server. The moment your request comes from a datacenter IP instead of a residential one, YouTube responds with LOGIN_REQUIRED or quietly serves nothing. Here's how VidTranscriber handles it. The problem There are two ways to get text from a YouTube video: Existing captions — if the uploader (or YouTube's auto-caption) provides them, you can fetch the caption track directly. Fast, free, no transcription needed. Transcribe the audio — pull the audio stream and run it through a speech-to-text model (Whisper-family). Works for any video, but costs compute. Both start with talking to YouTube from your server — and that's where it breaks. YouTube aggressively gates datacenter traffic: the watch page and InnerTube API return LOGIN_REQUIRED , and naive audio fetching gets reCAPTCHA'd. The approach The fix is to separate where the request originates from where the work happens : A Cloudflare Worker handles the user request and orchestration. Caption/audio fetching is routed through a path whose egress isn't treated as a bot — so the LOGIN_REQUIRED wall doesn't trigger. Captions, when available, become the primary path (no transcription cost). Only when there are no usable captions do we fall back to downloading audio and running Whisper. Long jobs go onto a queue (Cloudflare Queues) so the request returns immediately and the transcript streams in as it completes. Why captions-first matters Most "transcript generator" traffic is for videos that already have captions — talks, tutorials, news. Serving those from the caption track is instant and free, which means the expensive Whisper path is reserved for the minority of videos that actually need it. That's the difference between a tool that's cheap to run and one that isn't. What's still hard IP reputation drifts — what works today can get throttled tomorrow, so the extraction path needs monitoring and fallbacks. Caption quality

Cloudflare recently described how a slowdown in its billing pipeline was traced to contention inside the query planning stage of ClickHouse. The team profiled the bottleneck and patched ClickHouse to replace an exclusive lock with a shared lock, drop the per-query copy of the parts list, and improve part filtering. By Renato Losio

I recently rebuilt my homelab from scratch. The goal was simple: one machine, everything containerised, zero exposed ports, GPU-accelerated local AI, and a fully automated backup setup. No cloud subscriptions for the tools I use every day. This is the full technical breakdown — what I'm running, how it's wired together, and the hard-won fixes that cost me hours so you don't have to repeat them. What I'm Running Eight services, 26 containers, one machine: Service Purpose Portainer Docker management UI Uptime Kuma Service monitoring (7 monitors) NocoDB Self-hosted Airtable — CRM & leads n8n Workflow automation Open WebUI Local AI chat interface Ollama Local LLM inference (GPU) AFF!NE Collaborative docs & whiteboards Plane Project management (roadmaps, sprints) Duplicati Encrypted daily backups Cloudflare Tunnel Zero Trust secure access — no open router ports All external-facing services sit behind Cloudflare Zero Trust with email OTP. No passwords to manage, no VPN clients — Cloudflare handles authentication at the edge. Architecture ┌──────────────────────────────────┐ │ Cloudflare Edge (Zero Trust) │ │ *.yourdomain.com — email OTP │ └──────────────┬───────────────────┘ │ HTTPS ┌──────────────▼───────────────────┐ │ Ubuntu Machine │ │ │ │ cloudflared (outbound tunnel) │ │ │ │ │ ┌─────▼────────────────────┐ │ │ │ homelab-net (bridge) │ │ │ │ │ │ │ │ portainer uptime-kuma │ │ │ │ nocodb n8n │ │ │ │ open-webui affine │ │ │ │ plane-* duplicati │ │ │ │ ollama (GPU passthrough) │ │ │ └───────────────────────────┘ │ └───────────────────────────────────┘ Everything runs on a shared Docker bridge network ( homelab-net ). The cloudflared container maintains an outbound-only encrypted tunnel — no inbound ports open on the router at all. Ollama runs in Docker with NVIDIA GPU passthrough. The AI model inference happens on the GPU, leaving CPU headroom for all other services. Prerequisites Ubuntu 24.04 LTS Docker Engine + Compose v2 NVIDIA GPU with driver 535+ NVIDIA Container Too

If you've ever built a REST API with Express, you've probably felt it. Middleware registration, type definitions, body parser setup, connecting Joi or Zod... the structure is simple, but the boilerplate is excessive. When I first saw Hono, I was skeptical. "Another Express clone," I thought. That changed when I actually ran it. Bottom line: Hono v4 is more than just lightweight and fast. TypeScript type inference flows naturally all the way to route handlers. Zod validation connects via a single official package. On Bun, response times are noticeably faster than Express. Everything in this post is based on what I ran in a sandbox in June 2026. Why Hono — Compared to Express and Fastify Understanding where Hono fits means answering three questions. Bundle size : Hono v4 core is about 12KB. Express is 58KB, Fastify is 77KB. The gap might not sound dramatic, but in edge environments like Cloudflare Workers or Deno Deploy, bundle size directly affects cold start time. Edge functions sometimes initialize a new runtime per request — smaller means faster first response. Runtime compatibility : Express is Node.js-only. Fastify targets Node.js by default. Hono was designed from the start to "run anywhere." The same code deploys to Bun, Deno, Cloudflare Workers, Node.js, and AWS Lambda Edge. TypeScript support : Express requires @types/express as a separate install, and properties added to req via middleware don't get type inference. Hono is written in TypeScript from the ground up, and the Hono<{ Bindings: Env; Variables: Variables }> generic gives you type-safe access to environment variables and middleware state. I'm not saying Hono is the right choice for every situation. If your team is deeply invested in Express, or you need a mature plugin ecosystem, there's no compelling reason to switch. But if edge deployment is the goal, or you want type safety from day one, Hono is the most convincing TypeScript API framework right now. Installation and First Server — Response in

I use "what is my IP" sites maybe once a month. Every time I end up on something covered in ads, calling three different tracking APIs, and showing me results I don't fully understand. So I spent a weekend building whatsmy.fyi. The thing I didn't expect: you don't need an IP geolocation API at all if you're on Cloudflare Workers. Every request comes with a cf object that already has your city, country, ISP, TLS version, HTTP protocol, and RTT. Free. Zero latency. The part I enjoyed most was the WebRTC leak test. It checks whether your browser is exposing your real IP through RTCPeerConnection even when you're on a VPN. I ran it on my own setup. It was leaking. Zero logs. Zero storage. Just your data, shown to you. https://whatsmy.fyi

Cloudflare recently added support for Claude Managed Agents, allowing developers to run and manage Claude agents within Cloudflare. Developers can connect agents to private systems, choose their runtime environment, and monitor agent activity using Cloudflare services. By Renato Losio