Whether a request enters the proxy, and where it goes next
Routing & DNS
Before troubleshooting routing rules, confirm that the app's traffic reaches the client. Before troubleshooting resolution, identify whether the app, system or core handles the domain.
Routing & DNS
Routing Rules
A ruleset that selects direct, proxy or blocked outbound traffic based on conditions such as domain, IP or port. The matching order, how multiple conditions within a rule are combined and the default outbound for unmatched requests all determine the result. “Global” in a client usually names a routing preset; it does not mean every app automatically sends traffic to the client.
Compare: System Proxy →
Routing & DNS
GeoIP
Rule data containing IP address ranges for routing matches, commonly organized by region or purpose. It is not a real-time location service; IP assignments can change with network deployments, and accuracy depends on how recently the data was updated. If a destination uses multiple service addresses, the rule matched also depends on the IP actually used for the connection.
Compare: GeoSite Domain Matching →
Routing & DNS
GeoSite
Rule data that groups domains by site, service or category for selecting an outbound by name. Available categories depend on the data file the client actually loads; not every label can be used directly. Domain categories do not necessarily correspond one-to-one with IP categories. After adding a rule, check the match in the logs.
Next: Rule Order & Default Outbound →
Routing & DNS
DNS
The system that resolves domain names to IP addresses and other records, forming one step in the domain access path. The app, operating system and proxy core may each handle resolution, so changing one DNS address in the client does not route every query through it. Check who sends the query, which outbound it uses and whether the result came from cache.
Next: DNS Query Paths →
Routing & DNS
FakeDNS
A mechanism that uses virtual IP addresses mapped to domain names to handle traffic; returned addresses are not the destination server's real addresses. When the request later reaches the core, it must recover the domain from the saved mapping before routing and connecting. Access can fail if DNS responses and traffic capture cover different scopes, or if a mapping is lost while the app still has it cached.
FakeDNS: How It Works & When to Use It →
Routing & DNS
DNS Leak
A DNS query sent through a different channel than the one specified by the intended resolution policy. Clarify the expected policy before deciding whether a query is a leak; a direct query may be an intentional local-resolution rule. Check system DNS, browser secure DNS, in-app resolution and core DNS separately rather than relying on a single test page.
Review the DNS resolution flow →
Routing & DNS
System Proxy
Proxy address settings provided by the operating system to applications; whether an app uses them depends on its implementation, and some programs use their own network settings. The system proxy determines whether a request reaches the local proxy, while core routing selects its outbound destination. After changing the listening port, check the address configured in the system proxy. Before closing the client, make sure the proxy settings are restored correctly.
Compare: TUN Traffic Capture →
Routing & DNS
TUN Mode
A way to capture IP traffic through a virtual network interface and system routing, useful for apps that do not use the system proxy. It usually requires additional permissions and interacts with DNS settings, the routing table and other network software, but does not guarantee that every app or protocol will be captured. If the network stops working after startup, check for routing conflicts and DNS paths; avoid stacking multiple traffic-capture tools.
Troubleshoot system networking & permissions →