Configuration

Most functions of Chute are controlled by the configuration file. You may edit it in your own text editor, or in the built-in editor of Chute iOS, Chute tvOS, Chute Mac (the main window's Config tab, or Preferences... in the older interface) or Chute Android. Chute Dashboard has no configuration editor — what it edits is the running engine's rules, never the file.

Chute iOS can sync configuration files through iCloud Drive, which is a licensed feature. Chute Mac has no iCloud sync of its own: there, sharing a file means picking one that happens to live in iCloud Drive from the import panel, and it is then referenced where it sits.

Configuration Sections

The configuration file is organized into named sections:

Notice: The sections [Panel], [Ponte], [MTProto], [Keystore], [Port Forwarding], [Testing], [DHCP] and [Snell Server] are recognized so that a Surge configuration does not error (each logs one notice), and their lines are preserved verbatim when the configuration is saved, but they have no effect in Chute.

DNS Section

The DNS-related [General] keys may equivalently be written under a top-level [DNS] section. Lines in that section are handled per key:

[DNS]
doh = https://dns.google/dns-query
hijack-dns = 8.8.8.8:53
*.example.com = server:1.1.1.1

Note: Because both line forms are accepted here, a [DNS] section may mix DNS server settings with per-domain overrides. Do not repeat the same setting in [General] and [DNS]: a second doh line, for example, is reported as a duplicate DoH configuration.

Note: fallback-dns-server and encrypted-dns-skip-cert-verification are read under [DNS] as well, even though they are not in the first row. A key that is not a DNS setting is not ignored here — it is read as a per-domain override, so a misplaced [General] key such as optimistic-dns = false silently becomes the mapping optimistic-dns → false. Only a line that the override parser also rejects gets a notice. See DNS.

Including Another File

A profile may pull in another file. Surge writes #!include <path>; Shadowrocket writes include = <other.conf> above the first section. Both are read, and the included file is spliced in where the directive stands, so a [Rule] fragment lands inside the section that names it.

#!include Rulesets/company.list

• The path is resolved against the directory of the file that names it, and may hold a * — #!include Rulesets/*.list pulls in a directory of rule fragments, in name order.
• Includes nest up to 8 levels deep, and a file already pulled in — the profile itself included — is not pulled in twice, so a cycle cannot run away; a profile that includes itself is simply ignored.
• An include is only expanded when the profile was loaded from a file. Handed to the engine as text — which is how a configuration usually crosses into the tunnel — there is no directory to resolve against, so the profile is reported as incomplete rather than treated as whole. The directive itself is preserved when the configuration is saved: it is written back exactly as it was read, and the included file's content is never written into the profile.

Comment

A line that starts with #, ; or // is a comment. The same three markers open an inline comment, but only right after a space or tab, and never inside quotes ("…" or '…', with \ escaping the next character). A URL's ://, a path such as a//b and an unquoted base64 value that happens to contain // or # therefore stay whole. Comments and blank lines are preserved when the configuration is saved.

Inline comments work differently in the rewrite sections and on the ssid / subnet lines of [Proxy Group]:

Directive lines — #!include, #!MANAGED-CONFIG, #!IOS-ONLY and the like — are read as directives before any of this applies. The files a rule set, a domain set or a proxy provider downloads are not configuration sections: only a whole line can be a comment there.