When hosting protection blocks our server

Many hosting providers put a protective layer in front of the site. It watches incoming connections and, whenever one looks suspicious to it, answers with a captcha, a JavaScript challenge or a plain 403 instead of the page. A visitor solves the captcha once and never thinks about it again. Our server cannot: it runs no scripts, keeps no cookies and has nobody to click the button – it receives the challenge page and takes it for the answer your site gave.

The awkward part is that this protection is often enabled by default, on a plan nobody configured, so a site that looks perfectly healthy in a browser can be closed to us from the day it joined.

What it breaks

Traffman reaches your site from the outside in three situations, and this kind of protection breaks all three:

• Client verification. Once the API key and secret are saved on your site, our server calls back to it to confirm that the client really belongs to that site. If a captcha answers instead, verification never completes: the client stays Awaiting confirmation, no confirmation email arrives and the exchange cannot start – see confirming a client.
• Content validation. Every item you push is fetched the way an anonymous visitor would fetch it. A challenge page is not an article, so the item is marked Invalid – usually every item at once, within the same hour – see how validation works.
• Clicks on your content. When a visitor clicks your item in a block on another member's site, the service checks the page at that very moment. A blocked check sends the visitor to our content unavailable page and the traffic is lost – see revalidation.

The blocks on your own site keep working through all of this, because those requests travel from your site to us and not the other way round. That is what makes the problem confusing: the site looks like a participant while its own content is quietly out of the exchange.

How to recognize it

The symptoms share one shape – everything done from your side succeeds, everything done towards your side fails:

• The client never leaves Awaiting confirmation, although the key and the secret are correct.
• Every pushed item turns Invalid, while the same addresses open normally in your browser.
• The plugin's Healthcheck tab reports that the connection or the content URL could not be read.

A page that opens in a private browser window but still fails our check is the typical picture: the protection lets browsers through and stops everything else.

Where the option lives

It carries a different name in every panel, so it is worth looking for all of them:

• Bot protection, Anti-bot, Bot Fight Mode
• Web Application Firewall, WAF, ModSecurity
• Proactive defence, Attack protection, Anti-DDoS, Under Attack Mode
• IP reputation, Country blocking, Rate limiting

In a hosting control panel these usually sit in a Security section. If the site is behind Cloudflare or another CDN, that is a second, independent layer with its own settings – turning the option off in the hosting panel changes nothing there. And WordPress itself can hold a third: security plugins such as Wordfence or All-In-One Security block "bad bots" on their own, from inside the site.

Two ways to fix it

Let our server through. The better option: the protection keeps doing its work for everyone else, and only our address is allowed in. Look for an IP allowlist, Whitelist or Trusted IPs field in the same section and add the address below. Some panels also accept exceptions by path – everything our server asks a WordPress site for lives under /wp-json/traffman/ – but an address exception on its own is enough.

Turn the option off. This affects the whole site, so it is for the case where there is no allowlist to add to – or for confirming the diagnosis: switch the protection off, run the healthcheck, switch it back on. If the check passes only while it is off, you have found the cause.

If neither is available in your panel, it is an ordinary support request. Something along these lines is usually enough: "Please add the IP address N.N.N.N to the allowlist of the site's bot protection and firewall – it belongs to a service my site works with, and its requests are being answered with a captcha."

Our server address

Requests from Traffman to your site always come from one address:

142.93.104.213

That is the address to put on the allowlist. If it ever changes, this page is updated before the change takes effect, so it is worth checking here rather than relying on an address written down somewhere else.

Checking that it worked

On WordPress the plugin answers on the spot: open Traffman → Settings → Healthcheck and press both buttons – Check the connection from the API server to your client and Check content URL availability on your site. Two success notices mean our server now reaches your site. Details of the tab are in installing the plugin.

A client left at Awaiting confirmation is not verified again on its own, so start the verification over yourself: on the API tab press Save once more with the same key and secret.

Content already marked invalid needs nothing pressed. Those items stay in the retry cycle and become valid again on the first successful check, although a long-broken item is retried rarely – see revalidation. Saving the post again in WordPress pushes it anew and schedules a fresh check straight away.

If your site runs its own integration instead of the plugin, the same two checks are available as API calls – see the API documentation.