This guide covers the essential first-use workflow: prepare a subscription URL, import the profile, choose Rule mode, enable the system proxy, and review connection logs to confirm routing. Continue with advanced DNS, TUN routing, and configuration syntax after the basic connection works.
Windows, macOS, and Linux clients commonly use labels such as “Config,” “Proxy,” and “System Proxy.” Android and iOS clients may use “Subscription,” “Policy,” “Start,” or “VPN.” Button locations can differ, but the workflow is the same. To choose a different installer, use the platform links above to switch to the matching tab on the download page.
First, make sure the client, subscription URL, and local network are all ready to use. Once these checks are complete, follow the steps in order to make it easier to identify where a problem occurs.
On desktop, use an installer that matches your processor architecture. On mobile, install the client from the appropriate store or download page. On first launch, the system may request network, VPN, or background permissions. These permissions determine whether the client can handle application traffic, so grant them according to the system prompts.
Subscription URLs are usually generated by a network service provider. Copy the complete link, including its protocol, path, and trailing parameters. Treat the URL as a private configuration entry; do not post it on public pages or share it in screenshots or logs.
Keep only one client responsible for the system proxy or VPN at a time. Other proxy apps, browser proxy extensions, packet-capture tools, and corporate network components may modify the same settings. The connection may appear normal while requests actually follow another route.
This guide focuses on common graphical clients and does not require manual YAML editing. If you plan to configure custom rules, DNS, Fake-IP, TUN routing, or a server environment, complete these four steps first, then visit the cross-platform guide for the relevant sections.
The goal is to obtain a usable profile and explicitly set it as the active configuration. Pasting the URL is not enough; also confirm that the download succeeded and the profile is enabled.
After launching the client, look for “Config,” “Subscription,” “Profiles,” or “Configuration Files.” Desktop clients usually place it in the left navigation, while mobile clients often put it on the home or settings page. You should find an option to add a URL, import from a URL, or create a subscription. If a name is required, use something recognizable, such as the service name or intended use. There is no need to put the full subscription URL in the name.
Choose “Import from URL” or a similar option, paste the complete subscription URL into the field, and click “Import,” “Download,” or “Update.” The client will then request the remote configuration. Normally, the page will show a profile name, update time, or selectable profile entry. The first request may take a few seconds. Do not repeatedly add the same URL, or the list may contain duplicate profiles.
If the list is still empty after importing, check the field for extra spaces, especially line breaks introduced when copying from a chat app. You can also temporarily disable the system proxy if it has not been configured yet, then try updating again. If the error says timeout, 404, or invalid content format, do not continue to the connection steps because the client has not obtained a usable profile. For specific subscription update errors, continue troubleshooting in the Help Center.
Once the profile appears in the list, click it or use the enable button on the right to make it active. Some clients indicate selection with a checkmark, green marker, or “Active” label. After this step, open the proxy page and look for policy groups or available proxy options. If the proxy page is still completely empty, the profile may not be enabled, or the subscription may use a format unsupported by the client.
The mode determines how requests are routed. For first-time setup, start with Rule mode, which uses the profile's rules to decide whether traffic should connect directly, use a proxy, or be blocked.
Open the “Proxy,” “Proxies,” or “Mode” page from the main navigation, then locate the Rule, Global, and Direct options. Some clients place the mode selector at the top of Settings, while others put it above the proxy list. Confirm the current mode, then review the policy groups below. Groups may be named Auto, Manual, Streaming, or something else depending on the subscription; clients and profiles do not all use the same labels.
Routes traffic according to the domain, IP, and network rules in the profile. Common local services can connect directly, while requests that need a proxy are sent to the relevant policy group. This is suitable for everyday use.
Routes most requests through one global policy. It is useful for briefly testing a proxy, but not recommended for long-term use if you do not understand the effect of the rules.
Requests bypass proxy policies. This can help determine whether a problem is related to the proxy, but it cannot verify the proxy connection itself.
Click “Rule” and confirm that it is selected. Then open the main policy group and choose “Auto,” an available proxy, or the default recommended by the provider. If several unfamiliar names appear, you do not need to edit every policy group. Keep the profile defaults and confirm only that the top-level policy has a selected option. This reduces variables during initial setup; if a particular site later fails, use the connection log to locate the relevant policy group.
After switching proxies, the client may need a moment to establish a new connection. Do not change DNS, ports, and rule files at the same time. Adjust one setting at a time so it is easier to tell whether the change worked. If every proxy appears unavailable, update the subscription once. If none becomes available, ask the provider to confirm the service status instead of repeatedly reinstalling the client.
This step sends system or application requests to the client. Desktop clients usually use the system proxy, while mobile clients establish a local VPN connection.
Windows, macOS, and most graphical Linux clients provide a “System Proxy,” “Set as system proxy,” or similar switch. Once enabled, the client directs the operating system's HTTP and HTTPS proxy traffic to its local listening port. The system may request permission, and macOS may require your system credentials to change network settings. After authorization, the switch should remain enabled; the tray menu or status area will usually show that the system proxy is on.
If the client shows a “Mixed Port,” keep the default for first-time use. Do not change it just to match another tutorial, because the system proxy port must match the client's listening port. Browsers that follow system network settings should work immediately. If a browser has a separate proxy extension installed, disable it first so it does not override the system proxy.
Android and iOS clients generally use the system VPN interface to handle traffic. Tap “Start,” “Connect,” or the switch on the home screen, and the system will show a VPN configuration permission prompt. After approval, a VPN indicator usually appears in the status bar and the client button changes to Connected. This VPN is the entry point for handling traffic on the device; the proxy mode and policies are still controlled by the imported profile.
Some Android systems restrict background activity after an app leaves the foreground. For the first connection, keep the client open in the foreground while verifying it. Once it works, use system settings to allow the required background activity. If iOS disconnects after a network change or long sleep, return to the client and reconnect; there is no need to import the subscription again.
The system proxy works well for browsers and common desktop apps that follow system proxy settings. TUN mode can handle more applications that ignore those settings, but it involves a virtual network adapter, routing, DNS interception, and administrator permissions. Complete verification with the system proxy first. Only if a specific app bypasses the proxy should you read the TUN section of the cross-platform guide. This keeps basic connection issues separate from routing problems.
Do not rely on the switch color alone. Reliable verification checks webpage access, the client's connection log, and the rules that matched.
Open a regular site that normally works without a proxy and confirm that it loads. If no webpages open after enabling the connection, disable the system proxy or VPN and check the original network first. If the original network works but fails with the proxy enabled, check the current proxy, the client's listening status, and the system proxy port before changing complex rules.
Open the “Connections” or “Logs” page, then refresh the browser. Normally, new domain requests or connection entries should appear immediately. Seeing requests means browser traffic has reached the client. If no new entries appear, the system proxy may be disabled, the browser may use separate proxy settings, or the application may not follow the system proxy.
Open a request in the connection log to see which rule matched and which policy was ultimately used. Requests to common local services should normally be direct, while proxy-only destinations should show the relevant proxy policy. Rule names vary between subscriptions, so focus less on a specific label and more on whether each request followed the expected direct or proxy route.
Visit a site that should connect directly, then one that requires a proxy. If both work and the connection log shows different handling policies, the subscription, Rule mode, system interception, and proxy are all connected correctly. If direct sites work but proxy destinations fail, check whether the selected proxy is available. If proxy destinations work but local services fail, check whether Global mode was selected accidentally or the profile's direct rules were overridden.
The underlying network and the client's forwarding path are working.
System traffic has reached the client.
Direct and proxy requests are being handled separately.
When verification fails, check from upstream to downstream: confirm that the subscription updates and is enabled, verify that the selected proxy is available, check Rule mode, then inspect the system proxy, VPN, or the application's own network settings. Change one thing at a time and test again. If the log shows a specific DNS, certificate, connection refused, or timeout error, visit the Help Center and search by error type.
Keep the currently working setup intact, then add features one at a time. If a later change fails, you can quickly return to a configuration that has already been verified.
After confirming that manual updates work, enable a reasonable automatic update interval. If policy groups change after an update, confirm again that the main policy still has a selection. Automatic updates cannot fix an invalid subscription URL or an error returned by the service.
If the desktop client should start with the system, also confirm that it restores the system proxy automatically. Starting the program without restoring the system proxy leaves browser traffic outside the client; leaving the system proxy enabled without the program running can break network access.
Before changing custom rules, DNS, or TUN settings, record the working profile and the state of key switches. If something breaks, restore the basic settings first, then determine whether the change came from the subscription, system permissions, or a new parameter.
Everyday setup is complete at this point. For cross-platform installation details, Fake-IP, DNS, rule syntax, TUN, or Linux service configuration, continue to the cross-platform guide. For a specific error, start with the Help Center.