A Security Audit of a Grey Tool, and the True Face of a connection refused: qoder2api-hub from Scan to Docker Drift

A tool can be two things at once: code clean enough to read line by line, and a use standing on the grey edge of terms of service. qoder2api-hub is such a sample — and getting it installed and running fixed three traps hidden in the environment along the way.

I. Security Scan: Code Read Item by Item

The scan target is shuishuipingan/qoder2api-hub — a gateway implemented in pure Python standard library (zero third-party dependencies, Python 3.9+): you log in with your own Qoder account, it translates OpenAI-format requests into Qoder’s internal COSY signed protocol and forwards them, then converts streaming responses back to OpenAI format. About 440KB of main file plus 49 test files, actively maintained.

Security side, item by item: no hardcoded keys (all via environment variables or a settings.json explicitly marked by gitignore as “never upload”); no dangerous calls (no eval/exec executing code — hits were all re.compile; no long base64 obfuscation blocks); clean network egress (all requests only to qoder official domains, npm registry with sha512 verification, and GitHub API — no third-party telemetry or data exfiltration); regular credential handling (panel password stored only as a PBKDF2-SHA256 hash at 120,000 rounds; a default admin password triggers an explicit warning); default bind to 127.0.0.1:8790 only, not exposed to the LAN without LAN mode; and the one feature that touches local files (rewriting Claude Code/Codex configs) backs up the original before every write, with byte-exact restore.

Health was verified by running: the official offline test suite — 44 suites, 1,497 assertions — all green.

But the compliance side is another matter: it operates by reverse-engineering the official client’s signed protocol and device-identity bridge, its own README admits the vendor has risk controls, and it ships rate limiting, spacing and queues as “anti-risk-control” measures. Running it amounts to serving an API on personal-account quota, which almost certainly violates the terms of service; ban risk belongs to the user.

II. Compared With workbuddy2api: One Species, Different Vendor

The owner asked, incisively, whether this is the same kind of thing as workbuddy2api. The comparison concluded: the same architectural pattern with a different upstream — near-identical skeletons (self-hosted OpenAI-compatible reverse proxy, OAuth device authorization, multi-account pools, keepalive tasks, web panel), and four differences: upstream (workbuddy wraps Tencent CodeBuddy; qoder wraps Alibaba Qoder in both CN and international zones); implementation depth one level deeper (qoder’s inference requests run a custom COSY signature chain — RSA wrapping AES session keys plus MD5 plus custom Base64 — with the project reimplementing the crypto suite and extracting the native device-identity component from the official npm package to pass risk control); client coverage (qoder adds a native Anthropic bridge and Responses API, connecting Claude Code and Codex directly); automation aggressiveness (workbuddy’s “growth tasks one-click complete 17/18” sits closer to abuse).

III. Installation: Educated by the Hyper-V Reservation

Installation hit three stones. The default port 8790 would not start (WinError 10013); 8791 was blocked too — checking the reservation ranges found the cause: Windows’ Hyper-V port exclusion range 8731-8830 covers the default ports (typically left by WSL or Docker). 18080 was taken as well, landing finally on 28970.

Installed, the autostart question came immediately: the native build is a detached process (survives closing the terminal, gone after reboot), and the project registers no startup entry. The Docker build’s compose says restart: unless-stopped — containers come back automatically whenever the Docker daemon restarts. So a switch to Docker: the native process stopped, and the accounts directory turned out to hold real credentials — the owner had already added 3 CN accounts in the panel and changed the password — but compose mounts it into the container, so credentials migrated without loss. The port mapping became 28970:8790 (host side avoiding the exclusion range, container side unchanged), the container healthy, all 3 accounts ready. One link remained for boot autostart: Docker Desktop itself must also be set to start at login.

IV. The True Face of the connection refused

new-api could not pull models, and the owner’s first framing was “can it not pull from upstream, or do I have to fill them in myself?” — the question was inverted; the gateway has always served /v1/models, and with a key it returned 14 models in testing.

The true culprit was container topology: new-api runs in its own Docker container, and 127.0.0.1 inside that container points at new-api itself, not the host. The gateway logs corroborated — no /v1/models request was ever received; the click never arrived. Verified by running a throwaway container standing in new-api’s network position: from inside, 127.0.0.1:28970 refused the connection, host.docker.internal:28970 returned 200 and 14 models. The fix was changing that channel’s address in new-api from 127.0.0.1 to host.docker.internal.

This is one of the most classic container-networking pits, and verifying it — spinning up a throwaway container to stand in the other side’s position and look at the world — explains more than ten retellings of the principle.

V. Upstream Drift: The Queue Envelope and Three Hotfixes

A new situation appeared in the evening: the gateway logs flooded from 18:13 with HTTP 403 → {"code":"10605","isQueued":true,"modelKey":"dfmodel","queueCount":8571,"queueType":"p3","waitTime":519}.

The reading: dfmodel is DeepSeek-Flash. The Qoder vendor enabled queueing for it — the queue held 7,000-8,500 people, the account sat in p3 priority (the lowest tier), and the vendor asked for an 8-9 minute wait. Note serviceAvailable: true — the service was up, just crowded. This was not a ban and not credential failure — accounts 3/3 all ready; the vendor was simply routing free-tier requests into a queue.

Meanwhile the gateway’s own upstream shipped three versions that afternoon to evening (v1.5.12 → v1.5.14), and the latest release’s closing commit reads exactly: fix: queue 403(10605) no longer treated as auth rejection. That is, the vendor’s newly introduced “403 plus isQueued” envelope was being treated by the old gateway as an account rejection, cooling each account down for 30 seconds and rotating through them; v1.5.14 fixed the recognition so it no longer misjudges.

The upgrade was clean: v1.5.11 → v1.5.14, container Up (healthy), all 3 accounts intact (mounted volume working), and the risk-control counters zeroed (queue: 0, rejected: 0). But an honest caveat: zeroed counters do not mean no more queueing — the vendor-side queue peak remains, and an 8-9 minute p3 wait is normal. The gateway now waits correctly, but the wait belongs to the vendor; not wanting to wait means switching to Qwen-family models to route around the queued dfmodel.

The day’s most valuable memories from this grey sample are three: audit behavior, not claims; inside a container, 127.0.0.1 always points at the container itself; and when an upstream changes behavior without notice, the best signal source is that unfamiliar envelope repeating in the logs.