Docker containers

Containers you start with docker run or docker compose up in a Wirescry terminal send their HTTP and HTTPS traffic through Wirescry, and trust its certificate. Your images, Dockerfiles and compose files stay as they are, and containers started outside Wirescry terminals get nothing. This is part of the free app, from Wirescry 0.1.16.

Which Docker

Docker	Set up
Docker Desktop on macOS or Linux	Yes.
Docker Desktop on Windows	Not yet (see Windows).
Docker Engine on Linux (rootful, the usual install)	Yes.
Colima, OrbStack, Lima or Rancher Desktop	Not yet.
Rootless Docker, and Podman	Not yet.
Windows containers	No.
Docker on another computer (tcp:// or ssh://)	No.

Setup → Docker says whether Wirescry sets up your Docker, and if not, why. Where it doesn't, containers are left as they are, and docker commands work as they always do.

Wirescry looks for Docker when it starts and when you open a terminal from it. If you start Docker after opening a terminal, open a new one.

Windows

From Wirescry 0.1.18, Docker isn't set up on Windows: terminals Wirescry opens talk to Docker directly, and containers' traffic doesn't go through Wirescry. 0.1.16 and 0.1.17 did set it up there, but docker run then printed its output and never finished. If a terminal opened by one of those versions is still open, close it, or clear its setting: Remove-Item Env:DOCKER_HOST in PowerShell, set DOCKER_HOST= in Command Prompt.

Using it

1. Open a terminal from Setup → Terminals, or set up one that's already open (see Capturing traffic).

2. Start containers as usual:

   docker run --rm curlimages/curl https://example.com/

   or docker compose up in your project.

3. Their requests show up in Wirescry.

In the container, the same tools as in a terminal are covered: see What's covered. Under Setup → Docker, Last container names the most recent container and says whether it was set up, or why it was left as it is.

How it works

A Wirescry terminal's DOCKER_HOST points at Wirescry, which passes every Docker command on to your own Docker. When a container is created, Wirescry adds to it:

Added	What for
HTTP_PROXY, HTTPS_PROXY (and lower case), NODE_USE_ENV_PROXY, WIRESCRY_PROXY	Send requests to Wirescry, at http://host.docker.internal:<port>.
NO_PROXY	Keep requests to localhost and between containers direct (see below). Added to the container's own value.
NODE_EXTRA_CA_CERTS, SSL_CERT_FILE, REQUESTS_CA_BUNDLE, CURL_CA_BUNDLE, GIT_SSL_CAINFO, PHP_INI_SCAN_DIR, JAVA_TOOL_OPTIONS	Trust Wirescry's certificate. Java also gets the proxy and the hosts to skip.
A read-only folder at /run/wirescry	The certificate and the settings files those variables name.
host.docker.internal, unless the container has it already	The name for this computer. Docker Desktop has it anyway; Docker Engine on Linux doesn't.
Labels starting app.wirescry.	Mark the container as set up, or as left as it is. Compose's own config-hash label changes too (see Compose).

Nothing changes in the image. Tools that call Docker themselves, such as Testcontainers or a Docker SDK, use DOCKER_HOST too, so the containers they start are set up the same way.

Containers calling each other

Requests from one container to another go directly, not through Wirescry: Wirescry runs on this computer, where those names don't resolve. Compose service names, container names, network aliases and the addresses of the container's networks are added to its NO_PROXY.

A container started before the one it calls may not know the other's name. If those requests fail, add the name to NO_PROXY in your compose file; your entries are kept.

Requests to host.docker.internal go through Wirescry, on to localhost on this computer, so calls from a container to a server on your machine show up too, including servers that listen only on localhost.

Your own certificate settings

If you set NODE_EXTRA_CA_CERTS, SSL_CERT_FILE, REQUESTS_CA_BUNDLE, CURL_CA_BUNDLE or GIT_SSL_CAINFO for the container, in a compose file or with docker run -e, Wirescry keeps yours. Tools that read it then don't trust Wirescry: their HTTPS requests through it fail with a certificate error in the container, and don't show up in Wirescry. The same variable set with ENV in the image is replaced. Your PHP_INI_SCAN_DIR and JAVA_TOOL_OPTIONS are kept, with Wirescry's added.

Compose

docker compose up in a Wirescry terminal recreates the project's containers that are running without Wirescry's settings, so they get them. Run it again outside Wirescry and Compose recreates them once more, without the settings. Recreating a container discards changes made inside it that aren't in a volume.

The proxy port

Each container is set up for the proxy port Wirescry had when it was created. If the port changes, which can happen between launches unless you fix it, containers set up for the old one can't reach Wirescry. docker compose up in a Wirescry terminal recreates them; recreate others yourself.

When Wirescry isn't running

• docker commands in terminals Wirescry set up can't reach Docker. Use another terminal, or start Wirescry again.
• Containers it set up keep their proxy settings, so their HTTP and HTTPS requests fail. That includes containers that restart by themselves (restart: always) and ones you start again with docker start. Recreate them outside Wirescry to drop the settings; for Compose, docker compose up does that.

Turning it off

Clear Set up containers started from Wirescry terminals under Setup → Docker. New terminals then don't get DOCKER_HOST, and terminals already open pass new containers on to Docker exactly as you wrote them. Containers Wirescry already set up keep their settings; docker compose up recreates them without.

Docker Engine on Linux

With Docker Engine on Linux, containers' connections come from Docker's bridge networks rather than from this computer. There the proxy also accepts them, but only from containers Wirescry set up, and from this computer's own address on a Docker bridge (containers using --network host). Other containers, and other computers, are still refused. Docker Desktop needs none of this.

A firewall that blocks containers from reaching this computer blocks the proxy too, and their requests hang. ufw, Ubuntu's firewall, does this once it's on. When it is, Setup → Docker says so and gives the command that lets Docker's networks reach Wirescry's proxy port, ready to copy; the note goes away once a container gets through. With port 8000, for example:

sudo ufw allow from 172.16.0.0/12 to any port 8000 proto tcp

The command includes any Docker network outside that range (Docker moves on to 192.168.0.0/16 once it has many). A fixed proxy port makes the rule last; without one, Wirescry can pick another port next time. For another firewall, allow the same thing.

Not covered

Last container under Setup → Docker says why a container was left as it is.

• Containers already running. Recreate them from a Wirescry terminal.
• The steps of docker build.
• Dev containers, BuildKit builders, and kind, k3d or minikube nodes: left as they are.
• Containers with no network (--network none), and ones that share the network of a container Wirescry didn't set up.
• IPv6-only container networks, and on Linux, networks other than Docker's bridges (macvlan, ipvlan).
• docker --context or -H, and a DOCKER_HOST your shell profile sets: these replace Wirescry's, and nothing is set up.