How Nohost Turns Whistle into a Multi‑User Remote Proxy Service

Whistle is a packet‑capture debugging tool; Nohost builds on it to provide a multi‑process, multi‑user remote proxy service that can be used by developers, testers, and product operators.

GitHub repository: https://github.com/Tencent/nohost

Each team member or business module gets a dedicated Whistle instance.

Each Whistle instance can host multiple independent environments.

Each environment can be configured with arbitrary Whistle rules.

Users select the desired environment via a page UI.

Nohost Basic Architecture

The core idea resembles Node’s cluster module: multiple processes are turned into a single‑process Whistle problem by assigning each team member or module a Whistle process and managing them with a Master process.

Interaction Flow Diagram and Implementation

When a page loads Nohost, a small dot (environment switch button) is injected into the lower‑left corner.

Clicking the dot opens an environment selector; the chosen account/environment is sent to the Master process.

The Master obtains a clientId, stores the clientId and the selected account/environment in an in‑memory LRU cache.

After the environment‑setting request returns or times out, the page refreshes; the Master retrieves the clientId, looks up the cached account/environment, and forwards the request to the corresponding Whistle process to apply the environment’s rules.

Thus each user or business only needs to manage its own Whistle process, enjoying the same functionality as a local Whistle instance.

Master Process Implementation

The Master process provides three main functions:

Inject the small dot (environment switch button).

Record the user’s environment‑selection state.

Manage Whistle processes and dispatch requests.

Injecting the Small Dot

Injection is not a simple script append; it requires HTTPS request parsing and HTML‑only injection, which Nohost handles via an internal Whistle process:

const startWhistle = require('whistle')

Whitelist configuration, rules.txt dynamic fetching, and private _rules.txt injection are illustrated below:

Recording User Environment Selection State

When a user selects an environment, the page sends a request like

/.whistle-path.5b6af7b9884e1165/whistle.nohost/cgi-bin/select?name=imweb&envId=test&time=1637026271911

. The special /.whistle-path.* path is intercepted by Whistle. The request includes the account name ( name) and the URL‑encoded environment ID ( envId).

The Master extracts a clientId from the x-whistle-client-id header, or falls back to the client IP ( x-forwarded-for or req.socket.remoteAddress) and stores clientId together with the name/env in the LRU cache via lru.set(clientId, name/env).

Whistle Process Management and Request Dispatch

Management of the worker Whistle processes is also performed by the whistle.nohost plugin, which implements rulesServer and tunnelRulesServer to set forwarding rules:

The plugin obtains the clientId, retrieves the selected account and environment, and if an environment is chosen, starts a Whistle process via pfork on a random port. The Master then routes requests to * internal-proxy://127.0.0.1:xxxxx so that the request reaches the appropriate Whistle instance.

Idle Whistle processes are automatically terminated after six minutes of inactivity, and the plugin’s full implementation can be found in the GitHub repository.

References

GitHub repository: https://github.com/Tencent/nohost

Documentation: https://nohost.pro/