Feature Overview

AI Booster provides controls for compatible connection profiles. Which controls appear depends on the platform, app version, system permissions, the active profile, and the current plan. Use the settings screens in your installed client as the source of truth; a control described here may be hidden or named differently on your build.

Connection modes

TUN does not guarantee that every application or protocol is routed. After enabling it, verify routing, DNS, and leak behaviour for the applications you actually use.

Node selection

A profile normally exposes a selector — the node currently in use — whose members can include individual endpoints and one or more automatic groups.

Balancer strategies differ in an important way:

• lowest-delay ranks members by measured latency and, with the core's acceptable-ratio guard, leaves out members far slower than the best one — including members that are not reachable at all.
• round-robin, consistent-hashing and sticky-sessions distribute by turn, by hash, or by session. They do not rank by health, so every member of the group receives a share of real traffic — including members that currently cannot connect.

If a profile contains endpoints that are unreachable from your network, a strategy that does not rank by health will send some connections to them, which looks like an intermittent failure rather than a dead node. Prefer a health-ranking strategy unless you have a specific reason not to.

What the latency number means

Latency shown next to a node is a round-trip time measured by the core against a test URL. It is an estimate taken at one moment, and it is useful for spotting endpoints that are far away or not responding.

It is not a bandwidth measurement. An endpoint can answer a small test request quickly and still deliver poor throughput, and the reverse also happens. Treat the number as "is this reachable, and roughly how far", not as "how fast will my download be".

Measurements also go stale. The core refreshes them on an interval and may stop refreshing while the tunnel is idle, so a figure shown after a long idle period can describe a node's condition from much earlier. Re-run the test before relying on it.

Routing

Route rules are evaluated in order, and the first match decides the action.

Matching conditions available in the underlying core include exact domain, domain suffix, domain keyword, domain regex, rule sets, IP CIDR, port, protocol, and network type. Keep specific rules above broad catch-all rules, and see the advanced configuration guide for a safe change-and-verify workflow.

DNS

DNS is resolved through servers named by the profile, which may differ for proxied and direct destinations. Depending on the build, the client may expose:

• separate resolvers for proxied and direct traffic,
• a resolution strategy such as IPv4-only or prefer-IPv4,
• encrypted transports where the profile specifies them,
• a fake-DNS option that answers with placeholder addresses so the real lookup happens at the far end of the tunnel.

DNS failures look like a total outage — pages do not load even though the tunnel reports connected — so when nothing resolves, check DNS before changing nodes.

Per-application routing

Some platforms can include or exclude specific applications from the tunnel. Availability and the exact wording differ by platform and version; where it is not offered, all supported traffic follows the profile.

Transport options

Where a profile and build support them, additional transport controls may be available, such as TLS fragmentation, padding, mixed SNI case, and connection multiplexing. These change how traffic is shaped on the wire. They interact with the endpoint's own configuration, so change one at a time and re-test; an option that helps on one network can break connections on another.

Traffic statistics

The client can display upload and download rate and session totals while connected. Counters are per session unless the build states otherwise, and they measure traffic through the tunnel — not traffic that bypassed it via direct rules or per-app exclusions.

What varies by platform

Do not assume a value read here matches your client. In particular:

• Local listener and control ports differ between platforms. Read the current values from the client's settings screen rather than copying a number from documentation.
• Available settings sections differ. Controls exposed on one platform may be absent on another.
• Protocol support depends on the build and the profile, not only on what the core can theoretically handle.