Define what an airport subscription actually provides
An “airport subscription” usually means a paid service that provides access to proxy nodes through a subscription URL. The service may generate a Clash-compatible YAML file, a Base64-encoded list, or a client-specific profile containing node details, policy groups, traffic limits, and update information. It is not the same thing as a Clash client, a mihomo core, or a VPN application. FlClash and other clients process the configuration locally, while the airport controls the servers, account system, subscription endpoint, and traffic policy.
Before paying, write down the exact product being offered. A monthly plan may include a fixed traffic quota, a speed limit, a number of simultaneous devices, access to selected regions, or a different node pool from the annual plan. “Unlimited speed” does not necessarily mean unlimited traffic, and “global nodes” does not guarantee that every listed location is available at all times. Some providers also separate the account dashboard from the subscription URL, so losing access to the dashboard can make it difficult to rotate a leaked token or change a plan.
| Item to verify | Questions to ask before payment | Why it matters |
|---|---|---|
| Traffic quota | How many GB are included, and when does the quota reset? | Prevents a low monthly price from hiding a very small allowance. |
| Speed policy | Is speed limited per account, per node, or during peak hours? | Explains why a fast test may not represent evening performance. |
| Device count | How many devices or simultaneous connections are permitted? | Several family devices may consume a quota or trigger connection limits. |
| Node availability | Are advertised regions permanent, rotating, or subject to maintenance? | Node names and locations can change without notice. |
| Refund policy | Is there a trial, refund window, or clear process for service failure? | Reduces the risk of paying for a service that cannot be tested properly. |
| Compatibility | Does the provider support mihomo, Clash-compatible YAML, and the required protocols? | Prevents a profile from importing successfully but producing unusable nodes. |
Inspect the provider and its public information
A reliable evaluation starts before the subscription link is imported. Read the provider’s service description, terms, privacy statement, acceptable-use rules, maintenance announcements, and support channels. The goal is not to find a service with no limitations; every infrastructure provider has limitations. The goal is to determine whether those limitations are stated clearly enough for you to make an informed decision.
Check the service identity and support process
Look for a stable service domain, a documented account dashboard, and a support channel that explains how to report outages or billing problems. A provider does not need to publish its physical company address to be usable, but an anonymous page with no terms, no privacy information, no maintenance history, and only a disappearing chat account deserves extra caution. Check whether the service domain uses HTTPS and whether the dashboard is protected by a strong password and, where available, two-factor authentication.
Review the wording around uptime carefully. “99.99% speed” is not a meaningful availability promise, and “dedicated bandwidth” may refer only to a server port rather than a guaranteed connection for each subscriber. Prefer concrete statements such as maintenance windows, traffic-limit calculations, concurrency rules, and the time zone used for quota resets. If a provider changes its terms, it should explain what happens to existing accounts and prepaid balances.
Evaluate the subscription endpoint without exposing the token
A subscription URL often contains a long access token. Treat the complete URL as a password: do not paste it into public issue trackers, screenshots, chat groups, online YAML converters, or URL inspection websites. If the provider offers a safe preview or a separate test link, use that instead of revealing your personal token. You can also inspect a response locally, but remove the token before saving diagnostic output.
curl -L --connect-timeout 10 --max-time 30 \
-A "clash.meta" \
-D response-headers.txt \
-o subscription.yaml \
-w "HTTP=%{http_code} SIZE=%{size_download} TIME=%{time_total}\n" \
"https://example.invalid/client/subscribe?token=REDACTED"
The result should be a configuration or encoded subscription that your chosen client can parse. An HTTP success status alone is not enough. A server may return a login page, a CAPTCHA, a JSON error, or an HTML maintenance notice with status code 200. Open the downloaded file locally and check whether it contains expected fields such as proxies, proxy-groups, rules, or a clearly documented encoded format. Never publish the file without removing node credentials, passwords, UUIDs, private keys, and subscription metadata.
Also observe how the endpoint behaves. Frequent redirects to unrelated domains, certificate warnings, unexplained requests to many third-party hosts, or a subscription URL that works only after accepting an unknown browser extension are warning signs. A provider may use a content delivery network or a subscription conversion service legitimately, but it should be able to explain the role of those domains.
Test performance instead of trusting advertised speed
Performance is affected by your ISP, location, time of day, destination, DNS path, congestion, protocol, and the selected node. A single speed test cannot establish service quality. Before buying a long plan, use the shortest available trial or a low-cost monthly plan and test the same nodes at different times. Record the test conditions so that you compare providers fairly.
| Test | What to record | Possible interpretation |
|---|---|---|
| Latency | Probe delay, packet loss, and test time | Low latency is useful, but it does not prove that downloads or streaming will be stable. |
| Download and upload | Destination, duration, and sustained rate | A high starting rate followed by a sharp drop may indicate congestion or shaping. |
| Connection setup | Time to connect and frequency of retries | Repeated handshake failures can point to an unstable node or protocol mismatch. |
| Long-session stability | Disconnects during a 30–60 minute session | Useful for video calls, remote work, downloads, and other continuous traffic. |
| Different destinations | Domestic, international, and service-specific results | A node can be excellent for one route and poor for another. |
In FlClash or another mihomo-based client, first import the profile and confirm that the configuration parses without errors. Select one node manually, then test the relevant policy group. An automatic url-test group may choose the lowest-latency node, but latency alone can favor a node that has poor throughput or unstable access to your target service. Compare manual selection with automatic selection rather than assuming the fastest probe is the best daily route.
Check whether the subscription uses protocol features supported by your client and core. Profiles containing Hysteria2, TUIC, VLESS, WireGuard, ShadowTLS, or mihomo-specific fields may not work correctly in an old classic Clash core. A profile can appear in the client while individual nodes fail because the core cannot parse a field or establish the required transport. Review the core log and node test result instead of judging only by the imported node count.
Verify routing and DNS behaviour
Determine whether the provider expects rule mode, global mode, or a custom policy group. Inspect the generated rules for direct traffic, proxy traffic, rejected traffic, private network ranges, and DNS requests. A profile that sends everything through a remote server may be inconvenient, slower for local services, or unsuitable for devices that need local network access.
When TUN mode is enabled, traffic from applications that ignore the system proxy can also enter the mihomo routing stack. This makes routing more complete, but it increases the importance of checking DNS and bypass rules. Confirm that local printer addresses, router administration pages, private IP ranges, and required work services are handled as intended. If the provider does not explain its DNS design, start with system proxy mode and a limited test rather than enabling TUN across every device immediately.
Review privacy, credentials, and security exposure
Using an airport subscription means trusting the operator with traffic metadata and, depending on the protocol and destination, the ability to observe connection information. HTTPS protects the contents of a properly secured HTTPS session from ordinary interception, but it does not make the proxy operator irrelevant. The operator may still see connection times, destination domains or IP addresses, account identifiers, traffic volume, and the IP address from which you connect. Read the privacy policy for retention, analytics, log sharing, abuse handling, and account deletion.
Be especially cautious with claims such as “zero logs” when there is no explanation of what the provider means by a log. Ask whether logs are kept for operational monitoring, how long they remain, whether support staff can access them, and whether third-party hosting or analytics services are involved. A privacy policy should identify the categories of data collected even if it cannot promise that no operational records exist.
- Protect the subscription token: Anyone with the URL may be able to download your profile or consume your quota. Rotate or revoke it if it is exposed.
- Remove secrets from exported YAML: Delete passwords, UUIDs, private keys, and sensitive node parameters before sharing diagnostics.
- Use a separate account password: Never reuse an email, work, or banking password on the provider dashboard.
- Limit local exposure: Keep
allow-lan: falseunless other devices genuinely need access to the local proxy. - Protect the controller: Bind the external controller to
127.0.0.1when remote management is unnecessary, and set a strong secret if the interface is enabled. - Review TUN scope: TUN can capture more application traffic than system proxy mode, so use it only when its broader coverage is required.
Do not install an unknown root certificate, browser extension, “special accelerator,” or remote-control tool merely to use a subscription. A proxy profile should not require disabling endpoint protection or granting unrelated administrator permissions. If a provider asks for your email inbox password, device management access, or a permanent remote desktop session, stop the purchase and find another service.
Check payment protection and recognize warning signs
Payment safety is part of service reliability. Before choosing an annual plan, confirm the final price, renewal behavior, supported payment methods, refund terms, and the identity shown on the payment page. A payment processor can provide useful dispute mechanisms, but it does not automatically verify the technical quality or legitimacy of a service. Save invoices, order numbers, terms shown at checkout, and support correspondence in a private location.
Prefer a payment method that gives you a clear transaction record and does not require sending a reusable secret to an individual. Be cautious when a seller pressures you to pay immediately through an irreversible method, offers a large discount only for a long prepaid period, or refuses to describe how refunds are handled. A service may legitimately support cryptocurrency or regional payment platforms, but the absence of any protected or traceable option increases your financial risk.
| Warning sign | Why it deserves attention | Safer response |
|---|---|---|
| No trial and no refund policy | You cannot evaluate compatibility or stability before committing. | Choose a short billing period and avoid annual prepayment. |
| Constantly changing domains | It may reflect operational instability, abuse complaints, or poor account continuity. | Ask why domains change and whether old tokens can be revoked. |
| Guaranteed anonymity or “unblock everything” claims | No provider controls every destination, detection system, or network condition. | Treat absolute promises as marketing rather than evidence. |
| Huge node count with no maintenance information | Many entries may be duplicates, stale, or overloaded. | Test a representative sample across regions and protocols. |
| Frequent unexplained outages | Repeated downtime may indicate overselling or weak infrastructure. | Review public notices and support response times before renewing. |
| Requests for unrelated software or permissions | These requests expand the security risk beyond proxy configuration. | Do not install the software; use a standard Clash-compatible profile or leave. |
Finally, calculate the real monthly cost after traffic limits, device limits, exchange fees, taxes, and renewal pricing. Compare the service against your actual needs: ordinary web access, international work services, streaming, gaming, travel, or several household devices each require different routing and stability characteristics. The best subscription is not necessarily the cheapest or the one with the most locations. It is the one whose limits are understandable, whose profile works with your mihomo-based client, whose routes remain stable during your usage hours, and whose privacy and payment practices you can accept.
After purchase, keep a private record of the dashboard address, subscription URL, renewal date, quota reset date, and the client configuration used for testing. Set the subscription update interval to a reasonable value instead of refreshing it repeatedly. In FlClash, make changes one at a time and retain a backup of any local rules or policy-group overrides. This makes it easier to distinguish a provider outage from a local configuration problem and gives you a clean basis for deciding whether to renew.