Chute Dashboard

Chute Dashboard is a free macOS application that connects to a running Chute — Chute iOS over Wi-Fi or a USB cable, or Chute Mac on the same machine — and shows what that instance is doing: every connection with the rule and policy that decided it, the decrypted request and response for hosts covered by HTTPS decryption, DNS answers, UDP sessions. It also lets you shape the traffic while you watch it: the MitM host list and every rewrite and mock family can be edited live.

This is not the Web Console. The console is served by the kernel itself and opened in a browser; Dashboard is a separate app that talks to the kernel over its binary control channel, which is why it needs external-controller-access on the device rather than external-http-controller. The two overlap, and each has things the other does not — see What Dashboard cannot reach.

Dashboard's interface is localized into the same languages as this manual, except Arabic; on an Arabic system it shows English.

Allowing Dashboard to connect

Nothing listens until the device says so.

Chute iOS — in the configuration editor open External Controller → External Controller Access:

1. Turn on Allow Chute Dashboard/Chute CLI to Connect.
2. Set a Port and a Password. The password cannot be empty, and it must be one of your own: a listener that is reachable from the network refuses to start with an empty or default password.
3. Leave Allow Access From Wi-Fi off unless you need it. Off is the default and means the listener stays on the phone itself — a USB cable still reaches it, other devices on the Wi-Fi do not. On means anyone on the network who knows the password can read everything the run has seen.
4. Save, then start (or restart) the tunnel. The Control Panel now shows External Access Port: <port> — that line is the confirmation that the listener is up.

Chute Mac — the same three values live in [General]:

[General]
external-controller-access = password@127.0.0.1:6170

127.0.0.1 keeps it to the Mac you are on, which is what a Dashboard running on the same Mac needs; a LAN address or 0.0.0.0 opens it to other machines. The configuration window's General section has fields for the same key.

Connecting

Dashboard opens with the Chute New Dashboard window; each connection gets its own window, so several devices can be open at once. Two ways in:

Machines you have connected to are remembered under Machine: for next time.

If the password is wrong the window says Password does not match. If the device goes away — the tunnel stopped, the cable was pulled, the phone changed networks — the Dashboard window reports Connection Closed and offers Reconnect; there is no automatic reconnection.

The window

The toolbar switches between five views — Active, Recent, DNS, UDP and MitM — and Filter shows or hides the filter bar. The panel in the lower left is the live upload and download speed; click it to expand the graph.

On the Active and Recent views the toolbar also carries two switches that act on the running kernel, exactly as the switches in the apps do:

• Record Traffic → Disable Traffic Recorder: turns on the capture of request and response bodies (the replica setting). Without it rows still appear with their routing, but the data tabs stay empty.
• Enable MitM (N rules) → Disable MitM (N rules): turns HTTPS decryption on for the N hosts in the MitM host list. The switch does nothing useful until the device has a trusted CA and at least one host — see the HTTPS decryption page.

Neither switch edits the configuration file; a restart returns to what the file says.

The sidebar groups connections by client: All Clients, then Local for clients on the device itself and Remote for other machines that use this Chute as their proxy. Selecting one narrows every list to it. When the device is Chute Mac, local clients are the applications, by name and icon, and the context menu offers Show in Finder.

Active and Recent

Active is what is open right now; Recent is the device's history, newest first, read back from the run's records. Both share one set of columns:

The Flags column is the quickest way to tell whether a rule you wrote is being applied:

Recent holds up to 5,000 rows; Load Older at the bottom of the list fetches the next page from the device, and the list refreshes on its own every few seconds. When the active list is longer than one control packet can carry, a note under the table says the kernel truncated it — the rows are there on the device, and Recent will show them once they close.

Right-click a row for Copy curl Command, Export Selected as HAR… / CSV… and Export All as HAR… / CSV…; an active row also offers Kill Connection, which closes it on the device.

Notice: A row is a connection, not a request. A keep-alive connection that carried several requests is still one row, and the captured data holds all of those messages back to back; the headers shown are one request's. A browser opening a page therefore produces fewer rows than the page has resources.

The filter bar

The filter bar narrows what is shown. It does not change what the device records — for that, use [Replica] on the device.

Clear Filters returns to everything.

Connection detail

Open a row for its detail window. The tabs, left to right:

General — what the list shows, laid out with room: the request line and status code; the outbound mode, the policy and the rule that matched; bandwidth and peak speeds; local and remote addresses; the start time; the SSL/MitM state (Intercepted, Header Modified, Body Modified, Mocked); and Rules Fired — every rewrite or mock rule that changed this connection, quoted in the rule's own words. A rule that does not appear here did not touch this connection.

Timing — how the connection's setup was spent, as the kernel measured it:

A slow request is usually slow in exactly one of these lines, and which one says where to look: DNS in the DNS section, Remote Ready in the policy or the server behind it, Active in the application itself.

Req Hdr / Resp Hdr — the headers as a table, with Query Parameters and Cookies broken out for the request and Cookies for the response. A header a rule modified is highlighted. Copy Selected copies the selected rows.

Req Data / Resp Data — the captured body, as Hex, Text, JSON (an expandable tree, with search) or Image (Fit / Actual Size); multipart bodies are split into their parts. Export as bin saves the raw bytes. The data is there only when recording was on when the connection ran, and only for hosts the [Replica] filters let through.

Notice: Bodies are shown as they were captured. A compressed response — Content-Encoding: gzip — is not decompressed here, so its Text and JSON views are noise; the Hex view and Export as bin give you the bytes to decompress elsewhere. The device refuses to hand over a body larger than 2 MiB, and the Hex view shows the first 1 MiB.

DNS and UDP

DNS is the device's resolver cache: each domain with the addresses it resolved to, the server that answered first (Chute queries every configured server at once — see DNS), the TTL and the record type. Right-click for Copy Domain, Copy IPs and Copy DNS Server.

UDP lists UDP sessions — host, server, policy and state. There are no bodies for UDP.

MitM Tools

The MitM view manages the five rule families on the device, in five panels: MitM Rules, Header Rewrite, Body Rewrite, Map Local and Map Remote. What is true of all of them:

• The list is the running kernel's copy of the rules, which starts as what the configuration file declared.
• Adding a rule sends it to the device, which parses it as it would parse a configuration line; a line that does not parse is refused with an error rather than stored.
• Changes live in the running kernel only. They are not written to the configuration file, and a reload or restart brings back what the file says. Use the panels to find the rule that works, then write it into the configuration.
• Whether a rule is being applied shows up in the list's Flags column (R, K) and in the detail window's Rules Fired.

MitM Rules — one host pattern per rule, host[:port][/path], with a - prefix to exclude: *.google.com, api.example.com:8443, api.example.com/v2/*, -*.apple.com. The same grammar as the hostname key on the HTTPS decryption page. The count on the toolbar's MitM switch is the length of this list.

Header Rewrite — a form: URL Regex, Request or Response, Add / Replace / Delete, Header Name, Header Value. Dashboard composes the configuration line for you; the grammar is on the Header Rewrite page.

Body Rewrite — one configuration line, typed as you would write it in the file: url-regex type pattern replacement, where the type is response, request, jsonpath-response or jsonpath-request. See Body Rewrite.

Map Local — URL Regex, a File Path (Browse…) and optional Response Headers, one Name: Value per line.

Notice: The file path is read by the device running Chute, at request time. A path on your Mac is meaningful when Dashboard is connected to Chute Mac on that same machine, and meaningless when it is connected to an iPhone — the phone has no /Users/…. For a remote device, put the content inline with the rule's base64= form (see Mock Response) through the device's own editor or the Web Console, or serve the file from a URL and use Map Remote.

Map Remote — URL Regex, Target and Type: header rewrites the request in place (Surge's Map Remote), 302 and 307 redirect the client, and reject, reject-200, reject-img, reject-dict answer without contacting the server. See URL Rewrite.

Exporting

• HAR — right-click on the list: the selected rows or all of them, as a HAR 1.2 file you can open in a browser's developer tools (Network → import), Charles or Proxyman. One entry per row; bodies are included when recording was on.
• CSV — the list's columns, for a spreadsheet.
• Copy curl Command — a curl invocation that repeats the request from your Mac, with its headers.
• Export as bin — one body, as captured.

Dashboard builds its HAR from what it has fetched. The kernel can also build one itself — with the matched rule, the policy and the fired rewrites in a _kl object per entry, and send/receive timings taken from the capture — via the console's Export HAR or GET /api/connections/export?format=har.

What Dashboard cannot reach

Dashboard speaks the kernel's binary control channel, and some of what the kernel can do exists only on the HTTP control API. For these, use the Web Console or the API:

• the diagnostic bundle, health, refusal counters and events;
• the per-rule hit totals of the console's Rules page, and the did this rule ever fire answer they give;
• the kernel's own HAR, above;
• the log.

Two more things worth knowing before you rely on it:

• Chute Android does not offer the binary channel, so Dashboard cannot connect to it. Android's own remote dashboard and the Web Console cover the same ground.
• On iPhone and Apple TV, HTTPS decryption and body capture are licensed features. Without a license Dashboard still connects and shows every connection with its rule and policy, but HTTPS rows remain opaque CONNECT tunnels, the data tabs stay empty and the MitM switch has no effect. See License and Activation.