Random Picks, Shuffled Passes, and Repeated Proxy Endpoints
Choose between independent random picks, a shuffled pass, and a no-immediate-repeat policy instead of treating a repeated endpoint as a broken rotator.
Proxy B, proxy B again, then proxy A. Your log looks suspicious, but a random picker is allowed to do exactly that.
Choosing from the same list on each request permits repeats. With two equally likely endpoints, the next independent selection has a one-in-two chance of matching the previous one. A short run containing repeats is not evidence that the picker ignored the list.
Choose the behavior you actually need
| Requirement | Selection rule |
|---|---|
| Every pick is independent | Choose from the eligible list each time |
| Use each endpoint once before starting over | Shuffle a copy, consume it, then begin another pass |
| Avoid the immediately previous endpoint | Exclude that endpoint before choosing |
For the last policy, handle the one-endpoint case explicitly:
candidates = [endpoint for endpoint in eligible if endpoint != previous]
if not candidates:
raise RuntimeError("No different eligible proxy is available")
selected = random.choice(candidates)This fragment assumes random is imported and the endpoint list is already validated. A public pool can start with the free proxy list when its protocols fit the eventual client; this selection rule still controls repeats. Whether to wait, reuse the sole endpoint, or stop is an application policy. An endless loop waiting for a different random value cannot solve a list containing only one distinct choice.
In a concurrent dispatcher, selecting and recording the previous endpoint also needs coordinated ownership. Otherwise two workers can both exclude the old value and select the same next value.
Finally, this rule concerns endpoint identity. Two different endpoints can lead to one public exit, and one provider endpoint can lead to several exits. Record those separately before deciding the rotation is broken.