# Platforms (/manage/clients/platforms)

> Install, configure, and update Pangolin clients, and shared DNS and routing preferences



Each client has a preferences window. On Mac and Windows, click the menu bar or system tray icon and select "Preferences". In the mobile apps, open the "Preferences" screen.

The preferences below are shared across GUI clients. Install steps, settings that exist only on one client, and updates are documented on that client's page.

To troubleshoot connection or configuration issues, see [Client Logs](/manage/clients/client-logs) for how to view logs on each platform.

<CardGroup cols="2">
  <Card title="Windows" icon="windows" href="/manage/clients/platforms/windows">
    Install the Windows client, set preferences, and update.
  </Card>

  <Card title="Mac" icon="apple" href="/manage/clients/platforms/mac">
    Install the Mac client, set preferences, and update.
  </Card>

  <Card title="iOS/iPadOS" icon="apple" href="/manage/clients/platforms/ios">
    Install the iOS app, set preferences, and update from the App Store.
  </Card>

  <Card title="Android" icon="android" href="/manage/clients/platforms/android">
    Install the Android app, set preferences, and update from Google Play.
  </Card>

  <Card title="Pangolin CLI" icon="terminal" href="/manage/clients/platforms/cli">
    Install the CLI on Linux, macOS, and Windows, including machine clients.
  </Card>

  <Card title="Olm" icon="terminal" href="/manage/clients/platforms/olm">
    Deprecated command-line client. Use the Pangolin CLI instead.
  </Card>
</CardGroup>

## Shared Preferences [#shared-preferences]

The following preferences control how your client handles DNS resolution and network routing. They are available on Mac, Windows, Android, and iOS/iPadOS.

### Enable Aliases (Override DNS) [#enable-aliases-override-dns]

When enabled, the client uses custom DNS servers to resolve internal resources and aliases. This overrides your system's default DNS settings. Queries that cannot be resolved as a Pangolin resource will be forwarded to your configured Upstream DNS Server.

**When to use it**: This is required if you use aliases on resources in Pangolin. Aliases are friendly domain names assigned to private resources. Pangolin resolves these alias addresses over a private DNS server running in your client.

**How it works**: The client loops back to itself to resolve the alias. This is why you may see your DNS server as an unfamiliar address (often like `100.90.128.x`) when this is enabled. When a request doesn't resolve to a Pangolin resource and is bound for another website (like `google.com`), it falls back to your configured upstream DNS server.

### DNS Over Tunnel [#dns-over-tunnel]

When enabled, DNS queries are routed through the tunnel for remote resolution. To ensure queries are tunneled correctly, you must define the DNS server as a Pangolin resource and enter its address as an Upstream DNS Server.

**When to use it**: Tunnel DNS is used when you want to send all DNS queries over the tunnel to a private resource made available in Pangolin. For example, if you host a DNS server like Pi-hole, you could define a private resource for Pi-hole on your remote network. Then in the Pangolin client, you would enable Tunnel DNS and set the host of the Pi-hole private resource as the tunnel DNS server.

**How it works**: When a request needs to be resolved, Pangolin sends it over the tunnel to the site of the private resource with your DNS server. You must enable DNS Over Tunnel and also set the upstream DNS server to your private DNS server.

This requires aliases "override DNS" to be enabled as well. This is because the client must take control of your DNS settings to route queries through the tunnel to your private DNS server.

<Warning>
  You cannot use an alias name for your DNS server. It must be the IP address
  of the resource. This is because it's pointing to the DNS server, so the DNS
  server can't resolve itself.
</Warning>

### Primary Upstream DNS [#primary-upstream-dns]

This is the DNS server used to resolve queries that are not bound to a Pangolin alias when Override DNS or DNS Over Tunnel is enabled.

When left blank, **System DNS** is used. This pulls the existing configured system DNS settings and applies them to the tunnel. If Tunnel DNS is enabled and System DNS is used, requests will likely fail if the DNS server is not accessible over the tunnel.

### Secondary Upstream DNS [#secondary-upstream-dns]

This is a fallback DNS server used to resolve queries that are not bound to a Pangolin alias when the primary server is unavailable. Ordering and priority of the server is not guaranteed, but it provides redundancy for DNS resolution. When left blank, **System DNS** is used, same as Primary Upstream DNS.

### Match Domains [#match-domains]

By default, when match domains are not set, all DNS queries are sent to the configured upstream DNS server. Match domains let you whitelist which domains should be sent to the upstream DNS server. When match domains are set, only matching queries go to upstream DNS; all other requests use the system's DNS servers.

**When to use it**: When you have a private or corporate DNS server for specific domains (for example, `*.proxy.internal` or `corp.example.com`) and want everything else resolved by the system DNS as usual.

**How it works**: With no match domains configured, every query is forwarded to your Upstream DNS Server. With match domains set, only queries that match the list are forwarded upstream; the rest use the system's default DNS servers.

### Exit Nodes Take Precedence Over Resources [#exit-nodes-take-precedence-over-resources]

By default this is disabled. When a client is connected using an exit node other Pangolin resources will still be accessible and resolvable even on other sites not designated on the exit node resource. In this way Pangolin is still split tunneling these destinations. By enabling this setting, you are configuring Pangolin to ignore other resources outside of the exit node. All traffic will flow to and through the exit node resource and DNS aliases and subnets on other resources will no longer function.

### MTU [#mtu]

You can set the maximum transmission unit (MTU) for the client’s internal WireGuard interface. This value is client-wide: every site the client connects to must use the same MTU on the site side, or you can see fragmentation, failed handshakes, or unstable tunnels. See the **mtu** option on [Configure Sites](/manage/sites/configure-site) and set the same value on each of those sites.

<Warning>
  Changing MTU is advanced and not recommended for most users. Only change it
  when you have a specific, well-understood reason (for example, a constrained
  network path or a requirement from your infrastructure team). If you do
  change it, you must update every connected site to the identical value.
</Warning>