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.
It's cool that you admit the caveats upfront. The really useful architectural stuff is the observation that only search.wb.ru gets throttled while card/reviews/basket scale without issues - that's immediately useful across different IP types since throttling happens server-side, so you don't need to mess with proxy-specific tweaks to make it work elsewhere.The basket-NN cache invalidation using hostCache.delete(vol) on failed hits is already in your code, which is solid. What really sells me on your credibility tho is that you actually backed off your run-2 conclusion when run-3 showed it was wrong, an author willing to call out their own measurement errors beats someone who doubles down every time. For anyone using this, hit the low-friction stuff first like does pagination loop? does silent-200 actually happen? to validate it works, then treat the pricier claims like penalty duration as ballpark estimates rather than gospel