mubeng: Check a Proxy List and Use Rotating Proxies
Check an owned proxy list, create a usable pool, expose a rotating HTTP endpoint, and distinguish node rotation from session and target failures.
A proxy list is not automatically a usable pool. Likewise, reaching a checker endpoint does not establish that a target collection task will succeed.
This tutorial moves from an owned list through checking and a local rotating endpoint to request observations. It does not collect public proxies or promise long-term availability.
Install and prepare the list
Download a matching binary from official releases, or install with Go:
go install github.com/mubeng/mubeng@v0.23.0
mubeng -V
mubeng -hEnsure Go's binary directory is on PATH and retain the actual version. The official usage guide distinguishes checking from serving.
Create proxies.txt:
http://user:pass@proxy-a.example.16yun.cn:8888
socks5://user:pass@proxy-b.example.16yun.cn:1080
http://localhost:1Replace the placeholders with your own nodes. The loopback address can illustrate a failing endpoint only if that port is actually unused on your machine. Keep credentials private and encode URL components correctly.
Check a small pool first
mubeng -f proxies.txt --check --goroutine 5 --timeout 10s --output live.txtFive checker workers and ten-second timeouts are starting values for this small task. Too-short timeouts reject slow nodes; long ones extend failure waits.
Inspect the output before reusing it. A custom report with extra columns is not automatically a valid proxy-list input. An empty usable list should stop the workflow.
The default checker establishes its own target and criteria. It cannot certify every business destination. Validate the actual target separately.
Start the rotating HTTP endpoint
mubeng --address 127.0.0.1:8089 --file live.txt --rotate 2 --method sequent --syncThe client-facing endpoint is HTTP even when some upstream nodes are SOCKS. Do not configure clients to use a SOCKS scheme for this listener.
Rotation two means a request-count policy, not a time interval. Failed requests also count. Default asynchronous processing does not guarantee the externally observed boundary of every N requests; sync makes this teaching sequence easier to interpret at the cost of serial behavior.
Observe separate requests
From another terminal:
for number in 1 2 3 4; do
printf 'request %s: ' "$number"
curl --silent --show-error --max-time 20 --noproxy '' --proxy http://localhost:8089 https://httpbin.org/ip
printf '\n'
doneSeparate curl processes reduce confusion from browser subresources and connection reuse. Record actual origin values rather than expecting a guaranteed pattern.
Different proxy nodes can share an exit IP, and an upstream can rotate independently. Correlate tool observations with your owned node information when proving which route was selected. Avoid dumping sensitive headers and bodies into shared diagnostics.
Reconsider session requirements before integration
Configure the collector with the local HTTP endpoint and verify that its library actually uses it. Other containers have different loopback environments.
Independent public requests may tolerate rotation. A task binding cookies to a stable exit needs fixed-node or explicit session handling. Faster rotation does not automatically improve success.
The initial example avoids error-driven rotation so failures remain visible. If adding it later, use finite limits and distinguish connection, authentication, rate-limit, and parsing failures.
Refresh and stop deliberately
Write new checks to a new file, inspect format and counts, then replace the active pool. If using watch mode, confirm the installed version's reload behavior and retain a rollback list.
Stop the foreground process with Ctrl+C. Daemon mode changes service ownership and should be managed explicitly rather than invoked repeatedly by each collector.
Troubleshoot
No nodes pass: inspect one known node's protocol, credentials, and connectivity before increasing concurrency.
A populated file cannot forward: verify it is a reusable list rather than formatted output, then inspect current node state.
The IP does not change: inspect request accounting, sync behavior, shared egress, and long-lived connections. Equal IPs alone do not prove a rotation defect.
Login repeatedly fails: establish whether the task requires stable egress; rebuild its session on a fixed route.
The pool shrinks after every error: target business failures are not evidence that a proxy is unusable. Classify before removing nodes.
HTTPS fails while HTTP works: inspect CONNECT capability, target conditions, and certificate errors. Disabling certificate checks is not a correctness fix.
Treat list checking, rotation, and business acceptance as separate stages so the next corrective action remains clear.
Need an enterprise proxy plan?
We can tailor architecture to your target domains, concurrency, and reliability goals.