Documentation
Set up a redirect, choose exactly which names it covers, and know what happens when rules overlap.
Set up your first redirect
- Tap Add Redirect and enter the domain an app will request, such as
app.mysite.com. Do not enter the destination here. - Choose a destination. This Network accepts an IPv4 address and can discover advertised web servers nearby. Elsewhere accepts an IPv4 address or a hostname.
- Choose Exact, Subdomains, or Pattern to decide which requested names the rule covers. The wider modes require Pro.
- Save the rule and turn on etc/hosts. The first time, iOS asks permission to add a VPN configuration. Only DNS lookups scoped by your rules—and HTTP or HTTPS traffic for an explicit port mapping—enter it.
- Open the domain in Safari or the app you are testing. Use the Lookups tab to see whether the request reached the extension and how it was answered.
A destination may include a port, for example 192.168.1.42:3000. That lets compatible HTTP and HTTPS clients open http://app.mysite.com without adding :3000 to the URL. The limitations are covered under Ports and HTTPS below.
How matching works
Matching is case-insensitive. The app normalizes pasted domains by removing a URL scheme, path, port, leading dot, and trailing DNS dot where appropriate. The three modes then compare that normalized name differently.
| Mode | Rule | Matches | Does not match |
|---|---|---|---|
| Exact | mysite.com | mysite.com | www.mysite.com |
| Subdomains | mysite.com | The root and every depth below it | notmysite.com |
| Pattern | api-*.mysite.com | api-v2.mysite.com | www.mysite.com |
Exact
Exact covers one name and nothing beneath it. Use it when only app.mysite.com should move and names such as api.app.mysite.com should keep their real DNS answers.
Subdomains
Subdomains covers the name itself and every child at every depth. A rule for mysite.com covers mysite.com, www.mysite.com, and api.staging.mysite.com. It does not cover a merely similar suffix such as notmysite.com; the dot boundary must line up.
Pattern
In a pattern, * means zero or more characters and can cross dots. Therefore *.mysite.com matches www.mysite.com and a.b.mysite.com. It does not match mysite.com, because the dot before the * is still required. Use Subdomains when the root should match too.
A pattern needs a fixed ending after its last * so iOS can route a useful DNS scope into the extension. Adjacent repeated stars are treated as one.
Which overlapping rule wins
Rule order is not priority. etc/hosts scores every enabled, valid rule that your plan allows, then uses the most specific match:
- Exact wins over every Subdomains or Pattern rule.
- Subdomains wins over every Pattern rule.
- Within the same mode, the longer normalized rule wins.
The mode is compared first, even if a lower-ranked rule contains more characters.
| Requested name | Matching rules | Winner |
|---|---|---|
api.mysite.com | Exact api.mysite.com; Subdomains mysite.com | Exact |
api.staging.mysite.com | Subdomains mysite.com; Subdomains staging.mysite.com | The longer staging.mysite.com rule |
www.mysite.com | Subdomains mysite.com; Pattern *.mysite.com | Subdomains |
api-v2.mysite.com | Pattern *.mysite.com; Pattern api-*.mysite.com | The longer api-*.mysite.com rule |
The editor rejects two rules with identical coverage. Different patterns can still overlap with the same specificity score; do not rely on their list order to break that tie. Make one rule more specific, or disable the one you do not want.
The winning rule controls both the DNS destination and whether its configured port is used. A narrower rule without a port therefore keeps traffic direct even when it sits inside a broader port-mapped rule.
Routing scope and broad patterns
Before the matcher can run, iOS needs a fixed domain suffix to decide which lookups to send to etc/hosts. Exact and Subdomains rules use their domain. A pattern uses the fixed labels after its last *: api-*.mysite.com is scoped to mysite.com.
That scope can be wider than the pattern. Names inside the scope that do not actually match are safely forwarded to the device's existing DNS resolvers, and appear as forwarded in Lookups. A pattern ending mid-label can be much broader: *ite.com can only be scoped to all of .com. The editor warns when a rule has to route an entire top-level suffix through the extension.
What DNS answers change
- A matching IPv4
Alookup receives the address in the rule. If the destination is a hostname, etc/hosts resolves it using the device's existing resolvers and returns its IPv4 addresses with a complete CNAME chain. - Matching
AAAA,HTTPS, andSVCBlookups receive a successful empty answer so a client cannot bypass the redirect with real IPv6 or address hints. etc/hosts does not currently accept IPv6 destinations. - Other record types, and names routed into the extension that do not match a rule, are sent to the DNS resolvers already active on the device.
A remote destination hostname cannot fall under the same rule that points to it; that would cause its own lookup to loop. The editor rejects that configuration.
Ports and HTTPS
DNS chooses an address, not a port. When a rule contains a port, etc/hosts also configures a local system web proxy for that winning rule. HTTP and HTTPS clients that honor the system proxy are connected to the configured destination port. Other protocols and clients that ignore the proxy still get the DNS answer, but choose their port normally.
The URL's protocol is preserved. Opening http://mysite.com sends HTTP to the configured port; opening https://mysite.com sends TLS there. Port mapping does not turn an HTTP server into an HTTPS server.
The request keeps the original hostname in its HTTP Host header and TLS server name. The destination server must be configured for that name, and HTTPS still requires a certificate trusted by the device and valid for it. etc/hosts never decrypts or rewrites the connection.
Caching, edits, and local servers
- Synthesized DNS answers use a 10-second TTL, but iOS and individual apps may cache longer. A hard reload, closing a tab, or relaunching the client may be necessary after a change.
- Saving, enabling, disabling, or deleting rules reapplies the split-DNS configuration and briefly restarts the tunnel. That interruption is expected.
- A local dev server must listen on the machine's network interface, not only
127.0.0.1, and its firewall must allow the connection. Use Check Reachability in the editor to test the destination. - A local machine's DHCP address can change. Reserve the address in your router or update the rule when it does.
Reading the Lookups tab
| Status | Meaning |
|---|---|
| Redirected | A matching A lookup was answered from a rule. |
| Suppressed | A matching AAAA, HTTPS, or SVCB answer was intentionally left empty. |
| Forwarded | No rule answered this name or record type, so the existing DNS resolver did. |
| Failed | The upstream lookup timed out or a response could not be returned. |
Lookups only shows DNS questions that reached the extension, not all browsing on the device. The extension keeps at most 200 entries in memory. The app can leave the last snapshot visible after the tunnel stops; a newly started tunnel begins a fresh list.
Free and Pro matching
Free runs up to three Exact redirects. Subdomains, Pattern, and additional redirects require Pro. A paused rule is kept exactly as written and starts working again when the plan allows it. On Free, the three eligible Exact rules are determined by their position in the rule list. A disabled rule still occupies its position, so delete an earlier rule if you want a later one to become eligible.
Still stuck? The support page has a focused troubleshooting checklist and contact details.