Add apify proxy check — verify proxy reachability against a real target

[l2ysho]

Summary

There is no way to ask the CLI whether Apify Proxy can actually reach a given target, or how much of the assigned pool is burned against it. This is the first question any scraper author has, and the answer changes concurrency, retry budget and pricing — but answering it today means writing a script.

Version: apify-cli/1.10.0 (d227b1f).

The situation that prompted this

Building an Actor against a target that serves plain HTML with no anti-bot challenge. Direct requests from a home IP: HTTP 200. Through Apify's shared datacenter group, mostly 403 — with the target naming the address in the body:

<H1>Forbidden</H1>You don't have permission to access this server. IP: <redacted>

Pinning one session per pool member to enumerate the pool, against four domains of the same target (d1-d4), gave (exit addresses redacted — they are live Apify infrastructure):

exit IP          d1    d2    d3    d4
pool-ip-2        403   403   403   403     <- blocked
pool-ip-3        200   200   200   200
pool-ip-1        403   403   403   403     <- blocked
pool-ip-4        200   200   200   200
pool-ip-5        403   403   403   403     <- blocked

2/5 IPs clean (40%)

That number is decisive and non-obvious:

• Concurrency — with 2 clean IPs, the 10–50 concurrent requests recommended for HTTP crawlers would hammer two addresses and risk burning them.
• maxRequestRetries — at a 40% hit rate the default retry budget fails outright a meaningful fraction of the time, which matters because Apify's own daily Store test marks an Actor under maintenance after three consecutive failed runs.
• Pricing — datacenter is effectively fixed cost; residential is metered per GB. Whether you need to escalate decides whether a pay-per-event margin survives.

None of that is discoverable without measuring, and measuring means knowing that sessions pin deterministically onto pool members, that api.apify.com/v2/browser-info reports the exit IP, and how to assemble the proxy username. That is a lot of platform knowledge to reproduce per project.

Suggested command

apify proxy check --url https://example.com [--groups DATACENTER] [--sessions 10] [--min-clean 0.3]

• enumerate the pool by pinning one session per member
• report per-IP status against the target (repeatable with several URLs)
• print the clean rate
• exit non-zero when it falls below --min-clean, so CI can gate on it

The non-zero exit matters as much as the table: pool health drifts as other tenants' traffic gets addresses blocked, so this belongs in a scheduled check, not only in a human's terminal.

Prior art

I wrote ~130 lines to do exactly this and would happily contribute it as a starting point. Everything it does is on documented endpoints — no new platform surface required.

Related: #1424, #1425, #1426.