Mubeng turns a proxy list into one rotating HTTP endpoint
Mubeng has two jobs. It checks whether entries in a proxy file respond, then it can listen locally and forward requests through those upstream proxies. The input pool may mix HTTP, HTTPS, SOCKS4, SOCKS4A, SOCKS5, and Amazon API Gateway entries because the client transport selects the matching scheme. Applications point at one Mubeng HTTP address while the tool rotates the upstream route sequentially or randomly. That is a useful shape for scraping tests, authorized security work, and comparing proxy providers.
The codebase is compact. Our checkout had 79 files, roughly 2,882 source lines, and measured 1.2 MB. Mubeng still covers authentication on its listener, live reload when a proxy file changes, geographic filtering during checks, retries, removal of failed entries, custom output templates, and daemon installation. A prebuilt binary or container avoids a local compiler. Source users can install with Go or run the Make target, which keeps the first evaluation simpler than a multi-service proxy platform.
Rotation boundaries require sync mode
The default asynchronous server does not promise that request number N+1 uses a different upstream immediately after the rotation threshold. The README explains that concurrent work can cross that boundary before the previous request completes. Passing --sync makes requests wait and gives the rotation counter a predictable order, at the cost of concurrency. Buyers should decide which property matters: request throughput or exact sequencing. A test that sends serial requests will not expose the behavior of the default concurrent mode.
Error options add another policy layer. Mubeng can retry a failed request on the same proxy, rotate after errors, remove a bad proxy, and cap total failures. Those counters mean different things, and a negative maximum can keep rotation going indefinitely. Our 230 downloaded Go packages do not make the chosen policy safe by themselves. Set bounded values, log final failures, and test a pool containing slow, dead, and authentication-rejected proxies before sending a long job through it.
What happened when we ran it
Our fresh Debian sandbox installed the Go dependencies in 47 seconds, downloading 230 packages. Building commit 2709fa9 also took 47 seconds. The repository includes a Dockerfile and 3 CI workflow files, while it has no top-level tests directory. Nothing in the install or build log required manual packages, credentials, or a privileged container. That makes the source path easy to reproduce even when the eventual proxy workload has more network requirements.
Tests finished in 17 seconds, with 3 passed and 0 failed out of 3. That is a clean result, but it is a narrow suite for a network tool spanning several proxy protocols, certificate generation, service installation, retry state, and signal handling. Open issue 315 reports that the Make test target omits the pkg/helper/awsurl package and its parser tests. A proposed change would use a module-wide short test command. Our measured count remains 3; the issue explains why maintainers are discussing broader coverage.
The listener is HTTP even with SOCKS upstreams
Mubeng accepts SOCKS entries in the pool, yet its limitations section says the rotating server itself listens only as an HTTP proxy. A SOCKS-aware upstream will still be used by Mubeng's client transport, but an application that requires a SOCKS4 or SOCKS5 proxy endpoint cannot connect to Mubeng in that mode. This distinction is easy to miss because the feature list names supported upstream schemes without describing the listener in the same sentence.
TLS handling also deserves an explicit decision. Mubeng uses GoProxy's built-in certificate authority and lets users export a generated CA from a local URL. Installing that CA allows controlled clients to trust connections passed through the proxy. Release v0.23.0 also says unsafe cipher suites became enabled by default. Neither fact belongs in an unattended rollout. Limit CA trust to a dedicated test profile, keep proxy credentials out of checked-in files, and confirm whether older cipher support is acceptable for the environment.
Daemon mode drops options and replaces its service
The README says enabling daemon mode forcibly stops and uninstalls the existing Mubeng service, then installs and starts it again. That behavior is convenient for a deliberate upgrade and surprising as an incidental flag. Issue 316 reports that the service argument builder leaves out --rotate-on-error, --remove-on-error, and three numeric retry limits. The direct process retains them, according to the report, while the installed child falls back to defaults. A pending pull request addresses the mapping.
Issue 314 identifies a separate lifecycle problem: a direct process catches an interrupt but does not register SIGTERM, so the normal shutdown path is bypassed. Container managers and service supervisors commonly stop programs with SIGTERM. The report includes a reproduction and points to a focused proposed fix. Until that change is in the version you deploy, test the exact stop signal and check whether in-flight requests finish. The successful 17-second unit run did not exercise a live service stop.
Current source activity is ahead of the latest release
GitHub recorded 2,537 stars and 31 combined open issues and pull requests when fetched. The last push was August 17, 2026, and several August issues already had matching proposed fixes. The latest tagged release, v0.23.0, was published August 2, 2025. The older tag alone does not show abandonment because source and tracker activity continued a year later. It does mean binary users must distinguish released behavior from fixes still waiting on the default branch.
For a local, authorized proxy pool, Mubeng earns a trial. It built without drama, its core interface is clear, and Apache 2.0 permits broad use and modification. The 3-test result is too small to settle protocol and service behavior, so production acceptance should include dead proxies, concurrency, certificate trust, retries, daemon arguments, and supervisor shutdown. If the only requirement is rotating upstreams behind one HTTP endpoint, that work is manageable. More general interception or arbitrary TCP proxying calls for another tool.