World Monitor pulls news, alerts and institutional feeds into one dashboard. Your browser never touches those sources. The server fetches every feed and hands you the result, so the address each source sees is the server's, and that is where the interesting part lives. We read release v2.10.0 on 20 September 2026 and then measured its claims from our own machine.
The list in the code
The feed handler carries a hard-coded set with a comment:
Domains that consistently block Vercel edge IPs
The rest of that comment says to skip the direct attempt for them and go straight to the relay, to avoid spending an invocation on a timeout.
Seventeen hosts are named. Four of them are public institutions: who.int, news.un.org, cisa.gov and iaea.org. The rest are news organisations and research bodies, from CNN and SCMP to the Moscow Times, the Kyiv Independent and the Atlantic Council.
This is a production list, maintained by someone with nothing to sell, of sources that refuse one hosting platform. It is the plainest evidence we have seen that the address matters, and it raises an obvious question that nobody seems to have asked.
What our own server got
Does that list describe hosting in general, or one platform's address ranges?
We took the ten hosts whose feed URLs are configured in the same release and asked each one from our own server, a Contabo machine in AS51167. The request copies the project's own headers and its twelve second timeout. Nothing else differs.
| Source | Answer to our server |
|---|---|
| Defense News | 200, a feed, 145,978 bytes |
| UN News | 200, a feed, 33,650 bytes |
| IAEA | 200, a feed, 10,910 bytes |
| WHO | 200, a feed, 140,955 bytes |
| Crisis Group | 200, a feed, 8,140 bytes |
| SCMP | 200, a feed, 83,898 bytes |
| The Moscow Times | 200, a feed, 31,637 bytes |
| Atlantic Council | 200, a feed, 167,899 bytes |
| CISA | 403, Access Denied |
| Island Times | 403, a browser check |
Eight of ten answered normally. Two refused.
Then we asked three feeds the project fetches directly, because they are not on the list. France 24 and TechCrunch answered. feeds.news24.com handed our server a challenge page.
So the list is real and it is not transferable. That project's platform is refused by seventeen sources. Our server is refused by two of them, and by one that they consider fine. A block list is a property of an address range, not of hosting as a category.
That is worth saying plainly, because the usual advice in this corner of the internet is that datacenter addresses get blocked and residential ones do not. The truer version is narrower. Some ranges are on some lists. Which lists you are on depends on where you host, and you can find out in an afternoon.
Which refusals an address fixes
The last row comes from their own build file. The relay container installs one extra package with this reason: Node's JA3 fingerprint is blocked by Akamai, and curl passes. One of their sources was not refusing the address at all. It was refusing the handshake, and the fix was a different client from the same machine.
We covered the same effect on our yfinance page, where the library imitates a browser handshake on purpose. If that is what you are meeting, no proxy will help, and a proxy that terminates TLS will make it worse.
Where an address can change
There are three places a feed request can come from, and only one of them is configurable:
| Where the fetch happens | What it changes |
|---|---|
| The edge function | the default, uses the platform's addresses |
| The relay host | a different address, set with WS_RELAY_URL |
| A search index | for three blocked sources the feed is a Google News search instead |
The function that fetches feeds declares an edge runtime. There is no Node process there to hand a proxy agent to, so the familiar environment variables are not the lever. The lever is which host performs the fetch.
That makes the relay the place where a proxy belongs. It is a plain container, built on a current Node, so it can carry an ordinary proxy configuration. And it is worth knowing what happens without it: with WS_RELAY_URL unset, the relay address is null and the seventeen relay-only sources throw immediately. Those panels stay empty no matter how good your address is.
Which proxy type fits it?
First, measure. Ask the sources you care about from the machine you host on, the way we did above, and see how many actually refuse you. For most feeds the answer will be none, and the cheapest fix is no fix.
For the ones that do refuse, residential is the type that changes the answer. Our own paired test is the size of that effect: 4 of 13 answers changed between a server address and a residential one.
Feeds are the cheapest traffic there is. The largest document in our measurement was 167,899 bytes and most were a tenth of that, so a per gigabyte line goes a very long way here. Put the line on the relay host rather than on the application, and consider an allowed address so no password sits in that container's environment: on a Residential Premium plan your machine's address can be allowed, up to 150 per plan. The residential proxies page lists the plans, and the plan API manages allowed addresses from code.
What breaks
- A few panels are always empty. Check whether those sources are on the relay-only list and whether you configured a relay at all.
- Every relay-only source fails at once.
WS_RELAY_URLis unset, so there is no second host to ask. - A source returns 403 with an Access Denied page. Your range is on its list. A different address is the fix.
- A source returns a browser check. That is a challenge, not a block list, and an address alone may not clear it.
- A source refuses the runtime but answers curl. The handshake is the problem. Change the client, not the address.
What this page does not cover
We read the release as text and did not run the dashboard. Our feed measurement is one request per host from one hosting address on one morning, not a study: a source that answered may refuse an hour later, and one that refused may have been having a bad day. We could test ten of the seventeen hosts, because the others have no direct feed URL in the release we read. We did not test a residential address against these feeds, so the paired numbers above come from our earlier sixteen URL test and are not extrapolated here. This project pushes daily and the release we read was twelve days old. We will read the list again and repeat the measurement by 20 October 2026.
Where to go from here
Proxies for last30days covers another research tool that reads news sources, and the runtime version that decides whether a proxy variable reaches half of it. Proxies for yfinance covers the handshake problem in detail, including why a proxy that inspects TLS makes it worse. Proxies for SearXNG covers what happens when the sources are search engines rather than feeds.
Sources
- The relay-only domain set and its comment, the feed handler with its allowlist, redirect check and browser headers, and the relay helper that reads
WS_RELAY_URL(api/rss-proxy.js, api/_relay.js). The relay container and its note about the TLS fingerprint (Dockerfile.relay). The three sources read through a search feed (src/config/feeds.ts). koala73/worldmonitor, release v2.10.0 of 8 September 2026, read 20 September 2026. - Our own measurement of 20 September 2026: ten relay-only feeds plus three comparison feeds, one request each from 169.58.183.155, with the project's own headers and timeout. Script and raw output are kept in the research folder of this page.
- Our paired address test of 19 September 2026: 16 URLs, plain requests, two runs from our server and two through a residential line of our house plan. Raw output is kept in the research folder of our OpenClaw page.
- Plans, allowed addresses and per gigabyte pricing. HProxy documentation, hproxy.com/docs, 20 September 2026.
