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/