Cloudflare Tunnel 1033 (cf_no_network) for Self-Hosted WhatsApp API: 6-Step Fix

What does “cf_no_network” mean in a Cloudflare Tunnel to a self-hosted WhatsApp API?

BLUF: cf_no_network is the operator shorthand for Cloudflare Tunnel's origin-unreachable error 1033. Cloudflare's edge reached the tunnel, but the tunnel could not connect back to the local origin — in SocialMate's case, the HTTP API on 127.0.0.1:3456. The failure is network reachability, not a WhatsApp or SocialMate license issue.

Cloudflare Tunnel creates a secure connection from your private network to Cloudflare without requiring a publicly routable IP on the origin. Cloudflare documents error 1033 as the tunnel being connected to Cloudflare but unable to reach the origin web server. cf_no_network is the same failure expressed as a local shorthand in API clients.

The edge connection and the origin hop are separate. A tunnel can be connected to Cloudflare's edge while the last hop to your machine fails. That is why a working cloudflared tunnel info does not rule out cf_no_network.

Why does cf_no_network appear on a self-hosted SocialMate API setup?

BLUF: On a SocialMate install, cf_no_network almost always traces to one of three local causes: the API listens only on loopback, a firewall or Docker network blocks the origin path, or the Cloudflare ingress or TLS settings do not match the local service. Fix the local path first; the signal is deterministic.

SocialMate 2.0.1, the current stable release, ships 35 webhook events, 9 of them free, and the local HTTP API runs on every tier, including Free. That means the failure path is fully inspectable without a Pro upgrade.

Cause 1: Loopback-only reachability. SocialMate's local API listens on 127.0.0.1:3456 by default on the desktop app. Same-host curl works, but cloudflared running inside Docker or on another host cannot reach the host loopback. The ingress service must point at an address cloudflared can route to.

Cause 2: Firewall or host isolation. Windows Defender, macOS Application Firewall, Linux ufw, or Docker's network namespace can drop the connection even when the service is listening. From Cloudflare's side this looks identical to a down origin.

Cause 3: TLS or ingress mismatch. If the ingress rule points to https://origin:3456 while SocialMate's API speaks plain HTTP, or if the public hostname does not match a proxied DNS record, the upstream connection fails. SocialMate's local API is plain HTTP on loopback; no origin TLS is required on that hop.

Official Cloud API vendors manage this layer for you, but you cannot inspect or fix a failing origin on their side. The WAHA alternative and Evolution API alternative posts cover the raw self-hosted trade-offs.

What is the first diagnostic check for a SocialMate cf_no_network tunnel?

BLUF: Start with a same-host HTTP check against the local API. Run curl to 127.0.0.1:3456, inspect the listening port with netstat, ss, or lsof, and use the in-app API Tester. If the local response is healthy, the problem is between Cloudflare and the host interface.

The local API runs on Free, so this diagnosis does not require Pro. A 200 with JSON proves the origin is alive. A 401 also proves reachability — the request arrived and the key was rejected. Connection refused means the service is down or bound to a different interface.

Step 1: Curl the local API

curl -i -H "x-api-key: sm_your_key" http://127.0.0.1:3456/v1/accounts

Step 2: Inspect the listener

On Windows:

netstat -an | findstr 3456

On Linux or macOS:

ss -lntp | grep 3456
# or
lsof -iTCP:3456 -sTCP:LISTEN

Look for a listener on 0.0.0.0:3456 or 127.0.0.1:3456.

Step 3: Use the in-app API Tester

Open SocialMate's API & Integrations hub. If the in-app tester succeeds while Cloudflare still reports cf_no_network, the origin is healthy and the path to cloudflared is the problem.

If the tunnel reports connected but API clients still see cf_no_network, the origin check is failing. The SocialMate local API docs include the endpoint reference and API key scope.

How do I fix cf_no_network in 6 steps for a named tunnel?

BLUF: Work through six ordered fixes: make the local API reachable to cloudflared, correct the ingress rules, disable TLS verification only for a self-signed HTTPS origin, align the public hostname with Cloudflare DNS, open the firewall port, and restart SocialMate before cloudflared. Validate after each change.

Step 1: Make the local API reachable to cloudflared

If cloudflared runs on the same host, 127.0.0.1:3456 is enough. If it runs in Docker or on another host, do not rely on host loopback. Route through a reverse proxy that forwards to 127.0.0.1:3456, or use the host IP with a firewall rule. The SocialMate API itself is local; the reachability is an ingress problem.

Step 2: Update cloudflared ingress rules

Make config.yml match the origin exactly:

ingress:
  - hostname: wa.yourdomain.com
    service: http://127.0.0.1:3456
  - service: http_status:404

Replace 127.0.0.1 with the reachable address if cloudflared is remote. Run cloudflared tunnel ingress validate; a return code of zero means the config parsed, not that the origin is reachable.

Step 3: Disable TLS verification only if appropriate

Add originRequest.noTLSVerify: true only for a self-signed local HTTPS origin. Remove it once the path is confirmed. Do not use it for a plain HTTP origin; TLS verification is not the issue there.

Step 4: Ensure the hostname matches Cloudflare DNS

The public hostname must exist as a proxied CNAME record pointing to the tunnel's <tunnel-id>.cfargotunnel.com address, and the ingress hostname must match exactly. A mismatch produces origin reachability failures.

Step 5: Open the local firewall port

Allow inbound TCP on 3456 for the interface cloudflared uses. Ubuntu example:

sudo ufw allow 3456/tcp

On Windows, add an inbound rule for LocalPort 3456. On macOS, allow the app in System Settings > Network > Firewall.

Step 6: Restart both processes in the right order

Start SocialMate first and confirm the API is listening. Then restart cloudflared:

sudo systemctl restart cloudflared

Check cloudflared tunnel info and the app's API logs. Start-order issues are the most common reason a working config breaks after a reboot.

Why does cf_no_network recur after a reboot or sleep?

BLUF: cf_no_network returns after a reboot or sleep because start order, DHCP changes, and network reinitialization races rebuild the origin path unpredictably. SocialMate Pro's auto-start and auto-reconnect reduce the window, but cannot force the OS network stack or lease table to be ready.

Start order. On boot, cloudflared may start before the SocialMate desktop app or VPS process has bound its API port. The tunnel then connects with an unreachable origin until the app finishes starting. Pro auto-start on boot and auto-reconnect accounts on launch reduce this window. The license-verification model also survives active offline periods of up to about 2 days before falling back to Free, so a short network blip will not demote a paid seat.

DHCP and IP changes. Home routers reassign private addresses after reboots or lease expiry. If the ingress uses a LAN IP like 192.168.1.20, that address can change overnight. Prefer a stable reverse proxy target or create a DHCP reservation.

Reconnection races. After sleep, network adapters, VPNs, and Docker networks reinitialize in unpredictable order. cloudflared reconnects quickly and then reports cf_no_network until the local interface is back. Restart cloudflared after the origin is up, or add a small retry delay. Pro auto-reconnect covers the WhatsApp session; it does not make the tunnel path permanent.

Does cf_no_network mean my WhatsApp account is banned or at risk?

BLUF: No. cf_no_network is network infrastructure noise. It happens before any WhatsApp request is sent and says nothing about how WhatsApp viewed your number, content, or behavior. Bans and account risk are a separate layer.

WhatsApp bans are always possible when automating outside the official Cloud API. SocialMate reduces risk with pacing profiles, session warming, a duplicate-content guard, live eight-factor risk scoring, and read-and-typing behavior, but it does not eliminate risk. No tool can guarantee a number will not be banned.

A reader seeing cf_no_network should fix the tunnel path first, then confirm account health separately. The Knowledge Base covers ban risk, number warming, and desktop versus VPS safety.

Which SocialMate tunnel path gives a stable webhook URL, and what does it cost?

BLUF: A Pro named tunnel gives a stable webhook URL and costs a flat $99 per year or $10 per month, with no per-message fee. Free Quick rotates its URL and is not reliable for webhooks. A VPS public IP also gives a stable URL without Cloudflare, but the datacenter IP carries lower network reputation than a home connection.

Pro named tunnel is the production route for external services like Shopify, WooCommerce, Make, and Zapier to post into the local API. The URL stays the same across restarts, so webhook registration is one-time. Pro is required not only for the named tunnel URL but also for media send, group ops, polls, locations, contact cards, the smart queue, scheduled messages, Agent Memory, per-account proxy routing, unlimited webhooks, and full message history. The current SocialMate release ships 35 webhook events, 9 of them free.

On a VPS, direct-IP access is free and tunnel-free; put TLS in front with a reverse proxy for the admin login. A datacenter IP is structurally less residential than the desktop app on your home network, and Pro per-account proxy routing can route a VPS account through your own residential or mobile SOCKS5/HTTP proxy to reclaim that factor. Bans remain possible; the network path is one of eight anti-ban risk factors, not a full shield.

The self-hosted WhatsApp messaging policy post explains why local data and flat pricing change the model. For the full API scope and ingress details, start at the SocialMate local API docs. See pricing for the named tunnel and High-Volume Mode.

Path	Pricing model	Stable webhook URL	Ban / account risk	Best for
Free Quick tunnel	Free ($0 forever), no per-message fee	No — rotating URL	Unchanged by tunnel; account health follows warming and risk score	Testing webhooks and one-off sends
Pro Named tunnel	Flat license: $99/yr or $10/mo, no per-message fee	Yes — named stable URL	Unchanged by tunnel; Pro adds High-Volume Mode after 72h warming, but bans remain possible	Production webhooks and API integrations
VPS direct IP (no tunnel)	Flat license (Free and Pro tiers support VPS direct-IP access; Pro adds per-account proxy routing and full API features)	Yes — your VPS public IP	Datacenter IP has lower network reputation than home; Pro per-account proxy routing can use residential/mobile IP	Always-on developer endpoints where a tunnel is unnecessary

Fix cf_no_network for a SocialMate named tunnel

1. Make the local API reachable to cloudflared If cloudflared runs on the same host, use 127.0.0.1:3456. If it runs in Docker or on another host, route through a reverse proxy that forwards to 127.0.0.1:3456, or use a reachable host IP with the appropriate firewall rule.
2. Update cloudflared ingress rules Edit config.yml so the hostname points to the correct service URL, usually http://127.0.0.1:3456 or the reverse proxy address. Validate with cloudflared tunnel ingress validate.
3. Disable TLS verification only if appropriate Add originRequest.noTLSVerify only for a self-signed local HTTPS origin, then remove it once the path works. Do not disable it for plain HTTP origins.
4. Ensure the hostname matches Cloudflare DNS Create a proxied CNAME record in Cloudflare DNS pointing to the tunnel's cfargotunnel.com address, and make the ingress hostname match exactly.
5. Open the local firewall port Allow inbound TCP on port 3456 in the operating system firewall or Docker network rules for the interface cloudflared uses.
6. Restart both processes in the right order Start SocialMate first, confirm the local API is listening, then restart cloudflared. Check cloudflared tunnel info and the app API logs.

Frequently asked questions

Is cf_no_network a WhatsApp ban?

No. cf_no_network is Cloudflare Tunnel's origin-unreachable error 1033. It occurs before WhatsApp is involved and says nothing about your number being flagged.

What is the difference between Free Quick and Pro named tunnel?

Free Quick uses a rotating URL, so it is not reliable for webhooks. Pro named tunnel gives a stable URL that survives restarts. Pro costs $99/year or $10/month as a flat license, with no per-message fee, and also unlocks media send, group ops, polls, locations, contact cards, the smart queue, scheduled messages, Agent Memory, unlimited webhooks, and per-account proxy routing.

Does cf_no_network happen on a VPS?

Yes. If the local API is not reachable from cloudflared, the firewall blocks the port, or the ingress rule is wrong, cf_no_network can appear on a VPS just as it does on a desktop. VPS direct-IP access removes the tunnel dependency, but cloudflared is still an option.

How much does a stable webhook URL cost?

A stable URL costs a Pro license: $99 per year or $10 per month flat, with no per-message fee. Free Quick tunnel URLs rotate and are not stable enough for production webhooks. A VPS direct IP is also stable and tunnel-free on any tier, but it uses a datacenter IP with lower network reputation than a home connection.

Does the Pro named tunnel require WhatsApp Business approval?

No. SocialMate uses your own WhatsApp number and runs on your own machine. No WhatsApp Business or Meta approval is needed for any tier, including the Pro named tunnel.

How do I test my tunnel URL before pointing Shopify at it?

Run curl from an external network against the public hostname, for example curl -i https://wa.yourdomain.com/v1/accounts with your API key. A 200 or 401 response confirms the tunnel reaches the local API. Only then configure the Shopify webhook.

Can a VPS direct IP get my WhatsApp number banned?

Bans are always possible, and a datacenter IP has lower network reputation than the residential IP you get when running SocialMate on your own desktop. Pro per-account proxy routing can route a VPS account through your own residential or mobile SOCKS5/HTTP proxy to reclaim that factor, but it does not eliminate ban risk.

Why does the local API check work but cloudflared still says cf_no_network?

The local check likely succeeds through loopback from the same host, while cloudflared cannot reach that interface. Route through a reverse proxy, use a reachable host IP, and check the firewall.

Does SocialMate's anti-ban engine affect cf_no_network?

No. The anti-ban engine governs WhatsApp send pacing, warming, and risk scoring. cf_no_network is a network reachability problem and must be fixed at the cloudflared and origin layer.

Do I need a Pro license to diagnose cf_no_network?

No. The local HTTP API, including read endpoints and plain text send, runs on Free. You can run the curl checks and use the in-app API Tester before deciding whether you need Pro's named tunnel or a VPS direct-IP route.