ActorForge

Thanks — and the server-side point held up. What actually moved the night window wasn't IP type but request shape: sending Origin/Referer on search turns a 429 into a 200 from the very same address, while an already-punished IP stays punished no matter what you send it through. Which is the uncomfortable version of your "you don't need proxy-specific tweaks": you don't, right up until the host has decided about your IP, and then nothing you send fixes it. Live numbers since the post, on scheduled canaries every 6 hours: the retry ladder carries almost everything, nights included — the one hard failure in a week was a run that hit the wall clock, not the block. And you're right about penalty duration being a ballpark; my own figure moved between runs, which is exactly why it's the claim I'd trust least in the article.

Fair hit on run 4 — the confound is real, and the clean experiment you describe (bounce to a fresh datacenter IP mid-penalty) is the one I skipped. Since publishing I got a partial answer from production instead: the actor now falls back to a different residential pool when search keeps 429-ing, and on the single night it actually triggered, the run finished on the fallback attempt after the original IP had been failing for four retries in a row. That leans toward IP-level state rather than datacenter load at that hour — but it's one night, not a controlled test. On the categorization: agreed, that's the more useful framing than "discovery is expensive". What I'd write today, roughly — Wildberries: measurable bottleneck at discovery, sliceable; Avito: discovery is cheap (sitemaps do it), enrichment is the wall; Lazada: hard transport ceiling that architecture doesn't move. Deciding which bucket a new target lands in, before writing any code, deserves its own section. Thanks for the read.