Using netsleuth’s node.js API, you can integrate netsleuth in to your project’s development environment for your team’s convenience.

All developers can use the CLI to manage their netsleuth configuration.

netsleuth.attach([options][, readyCb])

The attach method attaches the netsleuth inspector to node’s core http and https modules. netsleuth monkey patches the core modules to install hooks which allow it to monitor every HTTP(S) request made from the node process. This means that no code changes are necessary in your application and you do not have to make requests through a proxy; request inspection “just works”.

The recommended way to attach netsleuth is by conditionally calling attach if running in a dev environment as the very first thing your application does:

if (process.env.NODE_ENV == 'dev') {

It is important that this happens before any other modules are required or imported so netsleuth can properly install its hooks before other modules have a chance to run.

After netsleuth patches the core http modules, it will optionally perform a number of other steps for your convenience:



The readyCb is invoked when netsleuth successfully connects to the daemon. Requests made before the daemon connection is ready are not buffered, so you may want to delay your application’s intitialization until this callback.


init() performs netsleuth’s project autoconfiguration without attaching the inspector to the process (ie nothing is patched).

Options are similar to attach() except name, transient, hooks, and initProject do not apply.


The InspectionServer class is normally instantiated by the netsleuth daemon at startup. InspectionServer provides facilities for inspection targets to submit their request/response events to the daemon. Normal user code should not need to use this class.

new InspectionServer([opts])


Note: the server does not start listening automatically; you must call server.http.listen(port) and/or server.https.listen(httpsPort).


Adds a new inspection instance. Inspection instances can be:

This method is ultimately what the CLI’s netsleuth inspect calls; see its documentation for a more complete explanation of the following options.


Some options only apply to remote and/or local inspectors for incoming requests.

Returns an Inspector instance.


Removes a remote or local inspection instance by hostname.

InspectionServer#inspectInproc(name, transient)

Adds an inproc inspector instance.


The GatewayServer class is normally instantiated by the netsleuth daemon at startup. When local mode inspection targets are added, they are added to the daemon’s default gateway. GatewayServer accepts incoming http(s) requests, forwards them to target server(s), receives and forwards responses to clients, and submits the request/response events to the InspectionServer. Normal user code should not need to use this class.

new GatewayServer([opts])



Processes running inside Docker containers may be inspected so long as the following caveats are observed.

Running the netsleuth daemon inside a Docker container is not a supported configuration; it is meant to run on your real machine. Processes running inside containers should connect to the global inspector daemon running on your host OS.

This means you should manually install the netsleuth CLI on your host machine and run netsleuth [start](/docs/cli#start) before starting your Docker container.

If netslueth detects that an inspected process is running inside a docker container, its behavior is altered:

The magic DNS name host.docker.internal resolves to your host OS LAN IP address. This feature requires Docker v18.03 or later. You must ensure that processes running in containers can reach the daemon (ie check your firewall). Note that docker-for-linux does not yet support this magic hostname. See the linked issue for workarounds.