WhatsApp Proxies: What 19 Fetches Show

WhatsApp is the network in this series with the least public surface. On 30 September 2026 we fetched it nineteen times through exits in the United States, Germany and India. A public channel page returned about 202 KB of HTML over plain HTTP with the channel name, its description and a follower count, and not a single post. The channel directory returned no channels at all. Rendering doubled the bytes and added nothing. The one thing the exit country changed was the follower count: the German page printed 593.386, the English one 593K. Here is what that means for a proxy buyer, and what the phrase "WhatsApp proxy" actually refers to.

What "WhatsApp proxy" means on Google

The autocomplete for "whatsapp proxy" is "whatsapp proxy code", "whatsapp proxy server", "whatsapp proxy settings iphone", "whatsapp proxy code india" and "whatsapp proxy code in pakistan". The first page of results is the WhatsApp/proxy repository on GitHub, two WhatsApp Help Center articles, a proxy-list site and its Reddit thread, and tutorials. The search behind all of it is reachability: people on networks that block WhatsApp looking for a way to connect.

WhatsApp answers that itself. Since 2023 the apps have had a proxy setting: in Settings, Storage and data, Proxy, you enter a proxy host, and WhatsApp connects through it. The proxy it expects is WhatsApp's own relay, an HAProxy container that Meta publishes as facebook/whatsapp_proxy. According to the repository README, it listens on 80 and 443 for web traffic, 5222 for the chat protocol, and 587 or 7777 for media. For a relay on a public address, the README recommends opening only 443 and 587, because unusual open ports make a relay easy to fingerprint. The setting is designed around that relay, so a commercial HTTP or SOCKS5 endpoint is not a drop-in answer to "whatsapp proxy code". If you want to run the relay, rent a small VPS in a country where WhatsApp is reachable, run the container, and share the hostname. Messages stay end-to-end encrypted; the relay only sees encrypted traffic.

Where a standard proxy does fit is anything that runs in a browser or a normal HTTP client: WhatsApp Web behind a corporate network, QA of your own WhatsApp Business flows from a customer's country, and reading the public pages below. The rest of this article covers those.

A public channel page has a name, a count and no posts

WhatsApp Channels are the only public broadcast surface WhatsApp has, and each channel has a web page at whatsapp.com/channel/<invite code>. We used the public channel of a large news broadcaster, the one its own site links to. We audited the page with and without JavaScript from all three exits and weighed it over plain HTTP.

Fetch	Exit	Bytes	Words, no JS / rendered	Follower count as printed
Channel page, no JavaScript	US	202,060	100 / 118	593K
Channel page, no JavaScript	DE	201,301	89 / 109	593.386
Channel page, no JavaScript	IN	207,684	96 / 118	593K
Channel page with ?lang=de	US	201,427	no-JS only	593.386
Channel page, rendered	US	394,034	rendered only	593K
Channel directory, /channel/directory	US	196,826	69 / 91	no channels listed

Here is everything the page tells a client with no account: the channel name as the h1 and title, the description the admin wrote, a line reading "Channel • 593K followers", the avatar URL on WhatsApp's media CDN, and two buttons that hand you to the app or to WhatsApp Web with the invite code. Posts are not on the page. The rendered pass was 394,034 bytes in 3.7 seconds, 1.95 times the plain fetch, and it had the same fields plus some interface text. Reading the posts requires following the channel from a WhatsApp account, and at that point you are inside the app, not on the open web.

Two meta details are worth noticing. Every channel page we fetched has robots: noindex and no canonical, so WhatsApp asks search engines not to index its channel pages. And /channel/directory, the "Explore Channels" link on WhatsApp's own marketing page, returned a 69-word shell that invites you to open the app: the directory exists only in the app. A web client cannot discover channels on whatsapp.com. It has to start from invite links that channel owners publish on their own sites and social profiles, which is how we found ours.

The exit country changed the number format

The three exits returned pages within 6,400 bytes of each other, with the same fields and the same no-post layout. The difference was the locale. The German exit got a German page, "WhatsApp-Kanal", with a description ending "wie bereits 593.386 weitere Personen": an exact follower count with a dot as the thousands separator. The US and Indian exits got English and the rounded "593K".

The IP is not what matters here; the locale is. Adding ?lang=de to the URL from the US exit produced the same German page and the same exact count, 201,427 bytes. For a census of channel sizes this is the most useful thing we found. The English page rounds to three significant figures, so it cannot show growth of fewer than 1,000 followers on a channel this size. The German page shows every follower. Parse it with the dot removed: a float parser will read "593.386" as five hundred ninety-three. To measure growth, request the locale, not the country, and use the cheapest exit available.

We found the same pattern on Facebook, where a German exit also changes number formats. Unlike on Telegram, where three countries got byte-identical pages, Meta's properties localise, and the localisation can be worth more than the geography.

robots.txt, the terms and the API

whatsapp.com/robots.txt is 1,180 bytes. Its header comments are the same notice Facebook uses: collecting data through automated means is prohibited without Facebook's express written permission. It blocks ClaudeBot, GPTBot, PerplexityBot, Google-Extended, Applebot-Extended, Amazonbot and Scrapy from the whole site, allows Meta's own crawlers everywhere, and for everyone else disallows only a short list of paths such as /ajax/, /login/ and *.php. The channel pages are not disallowed. They are noindexed, and the notice at the top of the file covers them.

The Terms of Service are more specific. Under "Harm to WhatsApp or our users" they prohibit, directly or through automated means: creating accounts through unauthorized or automated means, collecting information of or about users in any impermissible or unauthorized manner, and selling data obtained from the service. Under "Legal and acceptable use" they prohibit bulk messaging, auto-messaging and auto-dialing. Most "best proxies for WhatsApp" pages sell exactly those things.

The programmatic route is the WhatsApp Business Platform, and IP addresses play no part in it. The Cloud API authenticates with an access token. A call to the Graph API without one returned HTTP 400, 221 bytes of JSON, OAuthException code 2500, "An active access token must be used". With a token, Meta documents the limits: 80 messages per second per business phone number by default, up to 1,000 by automatic upgrade, error 130429 above that. New business portfolios can message 250 unique users per 24 hours, rising to 2,000, 10,000, 100,000 and unlimited as quality holds. These limits apply to the business, not to an address, so a proxy in front of the Cloud API does nothing except add latency.

Which proxy WhatsApp actually needs

For each real job there is a clear answer.

• Reading public channel pages (brand monitoring, audience sizes of news and brand channels, checking that your own channel's description renders in each language): the cheapest rotating exits from $0.50/GB, plain HTTP, never rendered. Nineteen fetches from three countries met no challenge page, no 429 and no empty shell; every page came back 200, two of them after one retry. Every response carries cache-control: no-store and no rate-limit headers, so the only warning of fetching too fast is a response that changes. Pace with your own counter.
• WhatsApp Web for a support team behind a network that blocks it: a sticky session on a residential address in the country of the business number, one account per session, or a SOCKS5 endpoint set at the browser or operating-system level. The goal is consistency, so the same account does not appear from a different city on every request.
• QA of your own Business flows (click-to-chat links, landing pages, the wa.me redirect, which returned a 191,723-byte "Open WhatsApp" page on api.whatsapp.com): residential exits in the markets you sell to, rotating is fine.
• The Cloud API: no proxy. The token is the identity, and the limits apply per business.
• The app on a blocked network: WhatsApp's own relay, described above.

Mobile proxies at $2.30/GB add nothing for any of these jobs. A WhatsApp account is tied to a phone number and a SIM, not to the carrier IP of the connection, so a 4G exit does not make an account more legitimate.

What a WhatsApp channel census costs

All figures at our published rates, counting a gigabyte as 10^9 bytes, using the byte counts measured above.

Job	Bytes per request	Requests per GB	Cost per request at $0.50/GB	At $0.80/GB residential
Channel page, no JavaScript	202,060	4,949	$0.00010	$0.00016
Channel page, rendered	394,034	2,537	$0.00020 plus 3.7 s of browser	$0.00032
Channel directory	196,826	5,080	no data to buy	no data to buy

A daily follower census of 10,000 public channels for 30 days is 300,000 pages. Over plain HTTP that is 60.6 GB, about $30 on rotating exits at $0.50/GB or $48 on residential Basic at $0.80/GB. Rendered, it would be 118.2 GB and $59 plus 250 hours of headless browser, for the same four fields. Through the web scraping API without rendering, the same 300,000 pages cost $0.0002 each, $60, with retries and rotation included and failed requests never billed. The same call is available to an agent through the MCP server.

These pages weigh about 200 KB to deliver fewer than 120 words, so the page-based API costs about twice the proxy bandwidth here. On Telegram the gap was wider, three to one, because its pages are lighter. If you run the loop yourself, read og:title, the description meta and the h1 from the head of the document, request ?lang=de to get the exact count, and skip the body.

The setting that works on WhatsApp

• Network: rotating proxies from $0.50/GB for channel pages. Sticky residential in the number's country only for a logged-in WhatsApp Web session.
• Fetch mode: plain HTTP, never rendered. Rendering returned 394,034 bytes against 202,060, with no extra data.
• Locale: ?lang=de for exact follower counts; any exit country works.
• Discovery: invite links from the channel owners' own sites. The web directory is empty and the pages are noindexed.
• Collector: there is no WhatsApp collector in our catalogue, and there should not be one: the public page has four fields and everything else is behind an account. For Meta's other public surfaces, the Instagram collector returns public profiles per delivered result.
• Free tier: every account gets $2 of free API usage per month, which is 10,000 channel pages through the scraping API before you pay anything.

What we will not help you do

Most of the "best proxies for WhatsApp" market is about running many accounts without getting banned: account farms, bulk senders, group "extractors" and number checkers that test lists of phone numbers against WhatsApp. The Terms of Service prohibit all of them by name, as quoted above, and a proxy does not change a word of that. WhatsApp's ban signals are the phone number, the device and the message patterns, not only the IP, so a residential address will not bring back a banned number. We will not write instructions for any of it.

What the public surface supports legitimately is narrow: sizing public channels, monitoring what brands and publishers announce there, checking your own channel page and click-to-chat links from your customers' countries, and running your own support team on WhatsApp Web from a consistent address. Everything else goes through the Business Platform, with a token, templates, opt-in and limits that Meta enforces per business.