Skip to main content

Rule System

The Rule System determines how Tachyon handles your network traffic. By defining specific criteria, you can decide which traffic should go through a proxy, which should access the internet directly, or which should be blocked entirely.

TYPE,VALUE,POLICY

How Rules Work​

Tachyon processes rules in a top-down sequence. When a network request is made, Tachyon matches it against your rule list. The first rule that matches the criteria will be executed, and any subsequent rules will be ignored.

Policy Types​

Every rule ends with an action. The three primary actions are:

  • DIRECT: Bypasses the proxy and connects using your local network.
  • DROP: Blocks the connection entirely (useful for ad-blocking).
  • proxy(name)/group(name): Routes the traffic through a selected outbound server/group.

Rule Types​

Tachyon supports several matching strategies to give you granular control over your traffic:

1. Source-Based Rules​

These rules focus on the origin of the request—usually the specific application or local device on your network.

  • SRC_PROCESS_NAME: Matches based on the application's process name (e.g., Telegram).
  • SRC_PROCESS_PATH: Matches based on the full file path of the application.
  • SRC_IP_CIDR4 / SRC_IP_CIDR6: Matches based on the local IPv4 or IPv6 address initiating the request.
  • SRC_PORT: Matches the local source port.

2. Destination-Based Rules​

These rules focus on where the traffic is trying to go.

  • DST_DOMAIN: Matches an exact domain name (e.g., google.com).
  • DST_IP_CIDR4: Matches a specific destination IP range (e.g., 192.168.1.0/24).
  • DST_IP_CIDR4 / DST_IP_CIDR6: Matches a specific destination IP range (e.g., 192.168.1.0/24, ffc0::/16).
  • DST_GEOIP: Matches the destination's country code (e.g., GEOIP,RU for traffic within russia).
  • DST_PORT: Matches the specific destination port (e.g., 443 for HTTPS).

When configuring DST_IP_CIDR4, DST_IP_CIDR6, or DST_GEOIP, if the rule requires resolving a domain name to an IP address, you can enable strict mode.

For example:

DST_GEOIP,HK,strict,DIRECT
DST_IP_CIDR4,8.8.8.8/32,strict,DIRECT
DST_IP_CIDR6,ffc0::/16,strict,proxy(trojan_example)

When a domain matches this rule, it will first be resolved to an IP address. Since this is a strict IP-based rule, the decision will be made based on the resolved IP rather than the domain name itself.

3. Rule-Provider​

Rule Providers allow you to import external rule sets (usually hosted via URL) to keep your configuration clean and automatically updated.

  • RULE_PROVIDER: Matches if the request criteria exists within the specified rule-provider list (e.g., an ad-block list or a streaming service list).

4. Logic-Based Rules​

Use these to create complex conditions by combining multiple rule types.

  • AND: Matches only if all nested sub-conditions are true.
  • OR: Matches if any of the nested sub-conditions are true.
  • NOT: Reverses the result; matches only if the condition is false.

Below is a conceptual look at how logical rules are structured:

StrategySyntax Example
Logic ANDAND,((SRC_PORT,1234),(DST_DOMAIN,google.com))
Logic OROR,((DST_DOMAIN,twitter.com),(DST_DOMAIN,x.com))
Logic NOTNOT,(DST_GEOIP,HK)

Final Policy​

If no rule matches, rules_final will be applied as the default (fallback) policy.

Best Practices​

  1. Order Matters: Place specific rules (like DST_DOMAIN) above general rules (like DST_GEOIP or DST_IP_CIDR4).
  2. DNS Resolution: IP-based rules often require Tachyon to resolve the domain to an IP address first. This may slightly impact performance if not configured correctly.
  3. Performance Hint: Place your most frequently triggered rules (like DST_DOMAIN) near the top of the list to reduce CPU overhead during the matching process.
  4. Use the Global Profile for universal rules you want to apply across all normal profiles, such as blocking known tracking or telemetry domains.