Two jobs that belong together
Mubeng combines a proxy checker with an IP-rotating proxy server. The checker takes a text file, tests entries concurrently, filters by country if requested, and writes the survivors. The server then presents one local HTTP endpoint while choosing upstream proxies from that pool sequentially or randomly. This pairing is sensible: rotation is only useful when dead endpoints are removed, and a checker is more valuable when its output feeds a real workload.
The project accepts HTTP, HTTPS, SOCKS4, SOCKS4A, SOCKS5, and Amazon API Gateway entries in the pool. Automatic transport selection means one file can mix those schemes. Callers do not need to understand that mixture because they talk to Mubeng's local listener. That is convenient for scraping code, command-line tools, or test software with a normal proxy setting.
It is also important to define the boundary. Mubeng does not provide proxies and cannot establish that a public endpoint is trustworthy. A successful check says the route answered the configured test, not that its operator will protect credentials, preserve content, or keep the same behavior tomorrow.
The checker is more than a ping loop
Checking supports configurable goroutine counts and timeouts, country filtering, verbose failure output, and file output. Version 0.23.0 added output templates with fields for protocol, host, external IP, country, city, organization, timezone, location, hostname, and response duration. That makes the result usable as a human report, CSV-like export, or JSON-like input for another step without a separate parser.
The rotation side has useful operational controls. Mubeng can rotate after a chosen request count, retry on errors, remove failing proxies, limit redirects, and watch the source file for changes. Authentication protects the local listener. Daemon mode installs it as a service, and the same binary runs on Linux, macOS, Windows, and Raspberry Pi-class systems.
The documentation does an unusually good job explaining details that otherwise become production surprises. Rotations count failed requests. Retries with the same proxy are distinct from errors that trigger rotation. A negative maximum-error value permits indefinite cycling. Verbose output redacts cookie values and omits bodies, while file logs omit request and response headers. These distinctions make the tool easier to reason about than its large flag list first suggests.
Concurrency changes what rotation means
Mubeng is asynchronous by default. When several requests are in flight, it cannot promise that the request immediately after a configured count will use the next proxy. The README recommends --sync when that boundary must be deterministic. This is a real tradeoff: synchronization provides ordering by reducing concurrency, while asynchronous operation preserves throughput but makes request-to-exit mapping less exact.
That distinction rules Mubeng out for workflows where a fixed group of related requests must share one identity unless the caller adds coordination. An older open request describes exactly this problem with parallel threads and pairs of requests. The tool can rotate every N requests, but application-level sessions are a different abstraction. Cookies, authentication, and server-side fingerprints can also link traffic even when the IP changes.
The public listener has another explicit constraint. Upstream SOCKS proxies work through automatic client transports, but Mubeng itself exposes only an HTTP proxy. A client that requires a SOCKS endpoint needs another layer or another product.
TLS and cloud routes add responsibility
For HTTPS inspection, Mubeng uses a generated certificate authority from the GoProxy stack. Clients must install that CA. This is standard for an intercepting proxy, but it grants the holder broad trust, so the key and certificate need careful handling. Do not distribute a development CA across unrelated production machines.
Amazon API Gateway entries offer another route shape. A pool can contain AWS regions, with credentials substituted from environment variables. Mubeng then creates or uses API Gateway resources to send traffic through multiple regions. This can be handy for geographic distribution, but it introduces cloud permissions, usage charges, provider policy, and credential exposure. The example is a starting point, not a cost or governance plan.
Recent issue activity highlights service-level gaps. One August 2026 report says daemon installation omits five retry and error options when reconstructing service arguments. Another says SIGTERM does not enter the graceful shutdown path, which matters for containers and service managers. Matching pull requests exist, but unpublished fixes should not be treated as part of v0.23.0.
Health and the decision
Mubeng's latest release arrived on August 2, 2025, and the repository was last pushed on October 8, 2025. In August 2026, contributors supplied focused reports and patches for daemon arguments, test coverage, and SIGTERM handling. That is useful activity, but the gap since the last push suggests a slower integration cadence. The open count of 31 combines issues and pull requests, including dependency updates and feature requests.
Documentation is the project's best maturity signal. The README covers every flag, output formatting, environment substitution, Tor stream isolation, Burp and ZAP chaining, AWS syntax, certificate installation, and the HTTP-listener limitation. Installation is just a binary download, Docker pull, or Go command.
Choose Mubeng when you want a compact checker and rotating HTTP gateway, already possess an approved proxy pool, and can test the service behavior you depend on. It removes a useful amount of glue without pretending to manage proxy reputation or session identity. For a critical shared service, pin a release, restrict listener access, protect any generated CA, monitor failures externally, and verify the open lifecycle fixes before relying on them.