Glossary · 26 common terms
Find terms by configuration layer, from subscription content to outbound rules. Each entry has a shareable anchor. New to setup? Start with the Getting Started guide. For protocol options and core differences, see Protocol Deep Dive.
Proxy protocols
A protocol defines how the client and server exchange data. Before choosing a proxy, check that the client supports its protocol, then verify authentication, security layers, and transport settings. The protocol name alone says nothing about speed.
An encrypted proxy protocol. A proxy config typically includes a server address, port, password, and encryption method. The client and server must support the same method. Variants such as Shadowsocks 2022 also require the matching key format. If import succeeds but the connection fails, check these fields before trying a different proxy name.
A proxy protocol in the V2Ray ecosystem that typically uses a UUID to identify users. A proxy may also use WebSocket, TLS, or other settings; the transport type and path must match the server. A significant clock difference can interfere with authentication, so check that the device time is correct if the connection fails.
A proxy protocol that typically runs over TLS and uses a password for authentication. In addition to the server address, SNI, domain, and certificate verification settings affect connectivity. For certificate errors, check the server details, device time, and certificate status, and keep certificate verification enabled.
A lightweight proxy protocol that uses UUID authentication but does not encrypt payloads on its own. Deployments usually pair it with TLS, REALITY, or another security layer. Preserve the transport type, security layer, and related settings when importing. Two proxies labeled VLESS may still require different client features because their configurations differ.
A QUIC-based proxy protocol that relies on UDP. Performance depends on UDP connectivity, congestion control, and bandwidth settings. It is designed for suitable network conditions, so evaluate it with your actual workloads. Hysteria v1 and v2 use different protocols; changing the name does not make an old config compatible with v2.
A QUIC-based proxy protocol that can carry TCP and UDP traffic. Check the server protocol version, authentication fields, and the client core's supported features. If the UDP path is restricted, switching to another proxy using the same protocol may not help; check the local network first.
Cores and clients
The client provides the controls; the core handles connections and rules. The same config can behave differently across apps because of core versions, config overrides, or system integration—not just interface differences.
In the software ecosystem, Clash can refer to the original rule-based proxy core or serve as a broad label for clients that follow its configuration conventions. An app with Clash in its name is not necessarily maintained by the same project or compatible with the same protocols. Before following a guide, check the exact app, core, and version.
A rule-based proxy core renamed from the Clash.Meta project. It handles proxy connections, DNS, and rule matching. It builds on the Clash configuration system and adds features, which is why older guides may still use the Meta name. New config fields require a compatible version; not every Clash core can read them.
An app that provides controls for managing subscriptions, choosing proxies, toggling connections, and viewing logs. FlClash is a client. The interface saves and organizes settings; an integrated proxy core typically handles traffic forwarding. Apps may combine subscription content with local settings, so check which config is active before editing the original file.
The underlying program that handles proxy protocols, traffic forwarding, DNS, and routing rules. Client interface updates and core updates are separate, and new controls may require system permissions to work. When troubleshooting a missing feature, include the app and core details rather than describing the interface alone.
Subscriptions and config files
A subscription is an update source, a config contains the active settings, and proxies provide connection parameters. These terms often appear together, but updates and edits affect different things. Before making changes, check which config the client is using.
A way to fetch and update proxies or a complete config from a link. The content may include only proxies or also proxy groups, rules, and DNS settings. Refreshing fetches the remote content again, so local changes made directly to a subscription file may be overwritten. Treat credentials in subscription links as sensitive. See subscription setup instructions for how to import one.
A set of proxy server connection settings in a client, usually including an address, port, protocol, and authentication details. A proxy name is just a label; a region in the name does not necessarily match the actual exit location. Connectivity depends on the settings, server status, and network path. A name appearing in the list only means its settings were read.
A text file that represents settings with indentation, key-value pairs, and lists. Clash configs commonly use this format. Indent with spaces, keep items at the same level aligned, and watch for quotes and colons. Passing YAML parsing only confirms the text structure is valid; fields must also meet the core's config requirements.
A separate collection of proxies in a config that can fetch proxies from a remote source and be referenced by proxy groups. It keeps proxy updates separate from the main config, making it useful when you want to update connection settings without changing local rules. Provider files must use a format supported by the core; not every full subscription file can be used as a proxy provider.
Converting proxy links or a subscription format into one recognized by a target client. Conversion may drop protocol fields that the target format does not support, or add proxy groups and rules from a template. Online converters can access the subscription content you submit. Prefer a compatible subscription from a source you trust, and assess the handling method if conversion is necessary.
Routing rules
Rules determine how requests are matched, proxy groups organize outbound options, and data files provide matching criteria. Understanding these three layers helps distinguish rule issues from proxy connection problems.
A way to choose direct, proxy, or another outbound policy for a request based on its domain, IP address, or a rule set. Rules are generally checked from top to bottom, with the first match taking effect. A final MATCH rule often handles the remaining requests. Rule mode does not send every request through a proxy; check the matched rule and its assigned policy to see what happened.
A config structure that organizes proxies or other policies under a single outbound entry. Rules can target a proxy group instead of a fixed proxy. Manual selection, URL testing, and failover use different logic, and switching proxies within a group usually does not require changing rules. Test URLs only show how a specific target performs; check real app traffic to assess automatic selections.
A separately maintained and updated collection of matching conditions, commonly declared with rule-providers and referenced using RULE-SET. The rule set provides matching criteria; the rule that references it usually determines the outbound policy. The file format, behavior type, and reference name must match. A successful download does not guarantee that the rules will match correctly.
Data used to match IP addresses by geographic location, commonly in a rule such as GEOIP,CN,DIRECT. It identifies the registered location of an address, not a website's language, company location, or content category. Database updates, address allocation changes, and CDN routing can all affect results, so GeoIP is best used as one routing signal among others.
A categorized collection of domain names that can be referenced with GEOSITE rules. Category names and coverage depend on the data source, so categories with the same name may differ across databases. Unlike GeoIP, it matches domains rather than address locations. Check core support, data source, and whether the target category exists before using it.
Network modes and DNS
How traffic enters the core and how it exits are separate questions. TUN and system proxy mainly affect the entry point; rules, proxy groups, and DNS settings work together to determine the final connection.
A way to route IP traffic into the proxy core through a virtual network interface and routing settings. The traffic captured depends on the system, routes, permissions, and exclusions. Once traffic enters the core, the outbound mode and rules still decide whether it goes direct or through a proxy. TUN may interact with other VPNs, virtual adapters, or LAN routes. When troubleshooting, change one traffic-capture setting at a time.
A way to point the operating system's proxy settings to a client's local listening port, commonly used by browsers and other apps that follow system proxy settings. Some programs use their own network settings and will not use this entry automatically. System proxy controls how traffic enters the core; the current mode and rules still determine whether it goes direct or through a proxy.
The system that resolves domain names to IP addresses and other records, an essential step before connecting to a website. System DNS, client DNS, and an app's own encrypted DNS can take different paths, so changing one may not affect the others. Results are also affected by caching and routing policies. When troubleshooting, check the query entry point, upstream resolver, and connection logs.
A DNS mode in which the client assigns synthetic IP addresses to domains and keeps a mapping between them. This helps match rules by domain during connection setup. Synthetic addresses are not the website's real server addresses, so they cannot be used to determine the outbound location. Some apps need real DNS results; for compatibility issues, check the exclusion list and clear relevant caches after making changes.
A DNS query taking a path other than the one intended—for example, when an app or the operating system sends a query to a different resolver than the client was expected to use. First clarify the intended policy, then check the app's encrypted DNS, system settings, and the scope of client traffic capture. A test page's reported resolver location is only a clue; a location label alone does not prove a leak.
The time required to complete a round trip or request under specific test conditions. Clients often test by requesting a URL, not necessarily by sending an ICMP Ping. The test address, timeout, connection reuse, and network path all affect the result. Low latency does not mean high download speed, and a timeout may simply mean the test target is unreachable. Judge performance using real requests from your apps.