TrendRadar watches hot lists and feeds across many platforms and pushes you a summary. It has more proxy settings than most projects in this series. Whether they apply depends on where you run it. We read the head of its main branch on 20 September 2026, because this project has no releases and no tags to pin to.
Four lanes
| Lane | What it fetches | What it needs |
|---|---|---|
| the hot list crawler | one document per platform | crawler.use_proxy and crawler.default_proxy |
| the RSS fetcher | your subscribed feeds | rss.use_proxy and rss.proxy_url |
| the notification dispatcher | pushes to your messaging channels | the address in use |
| the version check | a file from a code host | the address in use |
Two of those are worth a second look. The notification lane is unusual. Most projects in this series route their fetching and leave their outbound pushes on the machine's own address. The RSS block also falls back to the crawler's address when it has none of its own. That is convenient, and it is how people get caught.
Each lane wants two things: a switch and an address. An address with the switch left off does nothing. That is the most common configuration mistake in this whole family.
The hosted run
This is the part to read before anything else.
The documented way to use TrendRadar is to fork it and let a schedule run it. At startup it decides whether to use a proxy like this:
if not self.is_github_actions and self.ctx.config["USE_PROXY"]:
self.proxy_url = self.ctx.config["DEFAULT_PROXY"]
The first half of that condition is the whole story. In a hosted run the crawler's address is never set, whatever the configuration says.
Credit where it is due: it tells you. The function prints one of three lines. In this case it is the one meaning GitHub Actions environment, not using proxy. If you configured an address and nothing changed, that line is in your log.
The exception
The RSS lane survives, and one line explains why:
rss_proxy_url = rss_config.get("PROXY_URL", "") or self.proxy_url or ""
RSS takes its own configured address first. Only if that is empty does it fall back to the crawler's, and the crawler's is the value that was cleared. So on a hosted schedule an RSS lane with its own address is still routed. One relying on inheritance is not.
That distinction is invisible from the configuration file, where both look like one setting.
A cheaper fix, from their own code
One more thing worth copying. Their version check does not reach for an address when a host is unreliable. It rotates through mirror sources, starting from the last one that worked. Anything not on that host is requested directly.
When one specific host answers you badly, a list of mirrors is cheaper than a proxy. Try that first.
Which proxy type fits it?
Honestly: only if you run this yourself.
On a hosted schedule the main lane cannot use a proxy at all. We would rather say that than sell you a line you cannot point at anything. The RSS lane is the exception, and giving it its own address is free.
If you run it on your own machine, residential is the type that changes the answer for platforms that sort by address. Our own paired test is the size of that effect: 4 of 13 sites. The traffic is tiny, a document per platform plus your feeds, so a per gigabyte plan lasts a long time. One scheduled machine also means one address, which is what allowed addresses are for. No password in the configuration file, and the machine allowed by its address, up to 150 per plan on a Residential Premium plan. The residential proxies page lists the plans, and the plan API manages allowed addresses from code.
What breaks
- The address is set and nothing changed. Check the use flag, then check for the hosted run line in the log.
- RSS is routed and the hot lists are not. That is the hosted run, working as designed.
- RSS stopped being routed too. It was inheriting the crawler's address. Give it its own.
- A notification failed after you set a proxy. The dispatcher uses the same address for the messaging channels.
- You cannot find the version you are running. There are none. Note the commit date instead.
What this page does not cover
We read the code as text and did not run the monitor, so we did not watch a fetch use an address, did not run it on a hosted schedule and did not measure its traffic. We read the crawler, the RSS fetcher, the configuration loader, the proxy setup, the version check and the dispatcher's signature closely. We did not read each notification channel, so we report that the dispatcher forwards the address rather than tracing it into every one. There are no releases here, so this page names the last push date it read, 13 September 2026. We will read it again by 20 October 2026.
Where to go from here
Proxies for World Monitor covers another monitor with a hosted fetch, and the list it keeps of sources that refuse its platform. Proxies for last30days covers a research tool where the runtime version decides whether a variable is read. Proxies for SearXNG covers per engine routing in a search service.
Sources
- The crawler's proxy argument and its request, the proxy setup that excludes a hosted run, the RSS address resolution and its combined condition, the configuration loader with both blocks and the inheritance rule, the notification dispatcher's proxy argument, and the version check that rotates mirrors (trendradar/crawler/fetcher.py, trendradar/main.py, trendradar/crawler/rss/fetcher.py, trendradar/core/loader.py, trendradar/notification/dispatcher.py, trendradar/core/cdn.py). sansan0/TrendRadar, head of master, last pushed 13 September 2026, read 20 September 2026.
- Stars, forks and the absence of releases. GitHub API, read 20 September 2026.
- 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.
