Project X

简体中文

English
Русский

简体中文

English
Русский

深色模式

路由 ​

路由功能模块可以将入站数据按不同规则由不同的出站连接发出，以达到按需代理的目的。

如常见用法是分流国内外流量，Xray 可以通过内部机制判断不同地区的流量，然后将它们发送到不同的出站代理。

有关路由功能更详细的解析：路由 (routing) 功能简析。

RoutingObject ​

RoutingObject 对应配置文件的 routing 项。

json
{
  "routing": {
    "domainStrategy": "AsIs",
    "domainRecover": "off",
    "rules": [],
    "balancers": []
  }
}

domainStrategy: "AsIs" | "IPIfNonMatch" | "IPOnDemand"

域名解析策略，根据不同的设置使用不同的策略。

  • "AsIs"：不进行额外操作，使用目标地址里的域名或者 sniff 到的域名。默认值；
  • "IPIfNonMatch"：一整轮匹配结束后，当没有命中任何规则时，将域名解析成 IP 再次进行二次匹配；
  • "IPOnDemand"：在开始进行匹配前，直接先将域名解析为 IP 进行匹配；

domainRecover: "off" | "SnifferFirst" | "IPReDisCover"

纯 IP 目标的域名恢复策略（用于路由匹配），默认值为 "off"。

  • "off"：关闭纯 IP 目标的域名恢复；
  • "SnifferFirst"：优先使用 sniffer 恢复到的域名；若 sniffer 无结果，再尝试 DNS 缓存反查（IP -> 域名）；
  • "IPReDisCover"：优先使用 DNS 缓存反查（IP -> 域名）；若反查无结果，再使用 sniffer 结果。

说明：

  • 该字段只影响纯 IP 目标。
  • 恢复出的域名用于路由匹配（RouteTarget），默认不会直接改写真实连接目标地址。
  • 若命中的路由规则启用了 reLookup，后续行为仍遵循 reLookup 逻辑。

实际解析行为会被推迟到第一次遇到 IP 规则以降低延迟。结果将同时包含 IPv4 与 IPv6（你可以在内置 DNS 的 queryStrategy 进行二次限制） 域名解析出多条 IP 时每条规则将依次尝试全部 IP，只要任意一 IP 符合要求即视为命中规则。

当开启 sniff + routeOnly 使路由系统可以同时看见 IP 和域名时，如果发生上述的解析，路由系统只能看到由域名解析出的 IP 而无法看见原始目标 IP, 除非解析失败。

当存在多个候选域名时（例如 sniff 结果与 DNS 缓存反查结果），纯 IP 目标下的优先级由 domainRecover 决定。

无论解析与否，路由系统不会影响真正目标地址，请求的目标仍然是原始目标。

rules: [RuleObject]

对应一个数组，数组中每一项是一个规则。

对于每一个连接，路由将根据这些规则从上到下依次进行判断。当遇到第一个带目标且生效的规则时，即将这个连接转发至它所指定的 destination（可指向 outbound 或 balancer）。

规则也可以不带目标，仅用于写入 ruleTag（规则标记），供后续 requireRuleTag 规则进行链式匹配。

TIP

当没有匹配到任何规则时，流量默认由第一个 outbound 发出。

balancers: [ BalancerObject ]

一个数组，数组中每一项是一个负载均衡器的配置。

当一个规则指向一个负载均衡器时，Xray 会通过此负载均衡器选出一个 outbound, 然后由它转发流量。详见 负载均衡（Balancer）。

TIP

outbound 与 balancer 共享 destination 命名空间，tag 不能重复，否则启动失败。

RuleObject ​

json
{
  "domain": ["baidu.com", "qq.com", "geosite:cn"],
  "ip": ["0.0.0.0/8", "10.0.0.0/8", "fc00::/7", "fe80::/10", "geoip:cn"],
  "port": "53,443,1000-2000",
  "sourcePort": "53,443,1000-2000",
  "localPort": "53,443,1000-2000",
  "network": "tcp",
  "sourceIP": ["10.0.0.1"],
  "localIP": ["192.168.0.25"],
  "user": ["love@xray.com"],
  "vlessRoute": "53,443,1000-2000",
  "inboundTag": ["tag-vmess"],
  "protocol": ["http", "tls", "quic", "bittorrent"],
  "attrs": { ":method": "GET" },
  "process": ["curl"],
  "destination": "direct",
  "ruleTag": "+rule name",
  "requireRuleTag": ["mark-a", "!blocked"],
  "reLookup": false
}

DANGER

当多个属性同时指定时，这些属性需要同时满足，才可以使当前规则生效。

  • 纯字符串：同下面的子串，但可以省略前面的 "keyword:" 开头。
  • 正则表达式：由 "regexp:" 开始，余下部分是一个正则表达式。当此正则表达式匹配目标域名时，该规则生效。例如 "regexp:\\.goo.*\\.com$" 匹配 "www.google.com"、"fonts.googleapis.com"，但不匹配 "google.com"。大小写敏感。
  • 子域名 (推荐)：由 "domain:" 开始，余下部分是一个域名。当此域名是目标域名或其子域名时，该规则生效。例如 "domain:xray.com" 匹配 "www.xray.com" 与 "xray.com"，但不匹配 "wxray.com"。
  • 子串：由 "keyword:" 开始，余下部分是一个字符串。当此字符串匹配目标域名中任意部分，该规则生效。例如 "keyword:sina.com" 可以匹配 "sina.com"、"sina.com.cn" 和 "www.sina.com"，但不匹配 "sina.cn"。
  • 完整匹配：由 "full:" 开始，余下部分是一个域名。当此域名完整匹配目标域名时，该规则生效。例如 "full:xray.com" 匹配 "xray.com" 但不匹配 "www.xray.com"。
  • 无点域名：由 "dotless:" 开头，余下部分是一个不能含有 . 的字符串。当域名不含 . 且此字符串匹配目标域名中任意部分，该规则生效。例如 "dotless:pc-" 可以匹配 "pc-alice"、"mypc-alice"，适用于内网 NetBIOS 域等。大小写敏感。
  • 预定义域名列表：由 "geosite:" 开头，余下部分是一个名称，如 geosite:google 或者 geosite:cn。名称及域名列表参考 预定义域名列表。
    反选语法：geosite:!cn 表示“非 cn”。
  • 从文件中加载域名：形如 "ext:file:tag"，必须以 ext:（小写）开头，后面跟文件名和标签，文件存放在 资源目录 中，文件格式与 geosite.dat 相同，标签必须在文件中存在。
    反选语法：ext:file:!tag。

TIP

"ext:geoip.dat:cn" 等价于 "geoip:cn"

别名: domains

TIP

反向域名规则（如 geosite:!cn 或 ext:file:!tag）会作为排除项，优先于正向匹配；如果仅配置反向规则，则表示“除这些域名以外全部匹配”。

ip: [string]

一个数组，数组内每一项代表一个 IP 范围。当某一项匹配目标 IP 时，此规则生效。有以下几种形式：

  • IP：形如 "127.0.0.1"。
  • CIDR：形如 "10.0.0.0/8"，也可以用 "0.0.0.0/0" "::/0" 来指定所有 IPv4 或者 IPv6.
  • 预定义 IP 列表：此列表预置于每一个 Xray 的安装包中，文件名为 geoip.dat。使用方式形如 "geoip:cn"，必须以 geoip:（小写）开头，后面跟双字符国家代码，支持几乎所有可以上网的国家。
    • 特殊值："geoip:private"，包含所有私有地址，如 127.0.0.1。
    • 反选 ! 功能，"geoip:!cn" 表示非 geoip:cn 中的结果。多个反选项之间是 AND 关系，而正选项、正选项和所有的反选项之间是 OR 关系，例如 ip: ["geoip:!cn", "geoip:!us", "geoip:telegram"] 匹配非美国并且非中国的 IP，或者是 telegram 的 IP。
  • 反选 IP/CIDR："!1.2.3.4" 或 "!10.0.0.0/8" 表示排除该 IP/网段。
  • 从文件中加载 IP：形如 "ext:file:tag"，必须以 ext:（小写）开头，后面跟文件名和标签，文件存放在 资源目录 中，文件格式与 geoip.dat 相同标签必须在文件中存在。

port：number | string

目标端口范围，有三种形式：

  • "a-b"：a 和 b 均为正整数，且小于 65536。这个范围是一个前后闭合区间，当目标端口落在此范围内时，此规则生效。
  • a：a 为正整数，且小于 65536。当目标端口为 a 时，此规则生效。
  • 以上两种形式的混合，以逗号 "," 分隔。形如："53,443,1000-2000"。

sourcePort：number | string

来源端口，有三种形式：

  • "a-b"：a 和 b 均为正整数，且小于 65536。这个范围是一个前后闭合区间，当目标端口落在此范围内时，此规则生效。
  • a：a 为正整数，且小于 65536。当目标端口为 a 时，此规则生效。
  • 以上两种形式的混合，以逗号 "," 分隔。形如："53,443,1000-2000"。

localPort：number | string

本地入站的端口，格式和 port/sourcePort 一致，在入站监听一个端口范围时可能有用。

network: "tcp" | "udp" | "tcp,udp"

可选的值有 "tcp"、"udp" 或 "tcp,udp"，当连接方式是指定的方式时，此规则生效。

由于核心很明显只支持 tcp 和 udp 两种四层协议，所以一个仅包含 "network": "tcp,udp" 条件的路由可以用于 catch all 匹配任何流量。一个使用例子是放在所有路由规则的最末尾用于指定没有任何其他规则时使用的默认出站（否则核心默认走第一个）

当然其他很明显能匹配任何流量的写法比如指定 1-65535 的 port 或者 0.0.0.0/0 + ::/0 的 ip 也有类似作用

sourceIP: [string]

一个数组，数组内每一项代表一个 IP 范围，形式有 IP、CIDR、GeoIP 和从文件中加载 IP。当某一项匹配来源 IP 时，此规则生效。

别名: source

localIP: [string]

格式同其他 IP, 用以指定本地入站使用的 IP(使用 0.0.0.0 监听全部IP时不同的实际进入 IP 将产生不同的 localIP).

对 UDP 无效(UDP 面向报文的原因无法跟踪), 总是看到 listen 的 IP

user: [string]

一个数组，数组内每一项是一个邮箱地址。当某一项匹配来源用户时，此规则生效。

类似于域名，其也支持类似 regexp: 开头的正则进行匹配。（同样需要替换\为\\, 见domain部分的解释）

vlessRoute: number | string

VLESS 入站会允许配置的 UUID 第七和第八个字节被客户端修改为任何字节，服务端路由会将其作为 vlessRoute 数据，允许用户不更改任何外部字段的情况下根据需求自定义部分服务端路由。

--------------↓↓↓↓------------------
xxxxxxxx-xxxx-0000-xxxx-xxxxxxxxxxxx

配置中使用的是大端序编码为uint16后的数据(听不懂的话，把这四位当成一个十六进制数并化为十进制) 如 0001→1 000e→14 38b2→14514. 这么做的原因是这里的写法同 port, 可以像指定 port 一样自由指定许多段进行路由。

inboundTag: [string]

一个数组，数组内每一项是一个标识。当某一项匹配入站协议的标识时，此规则生效。

protocol: [string]

一个数组，数组内每一项表示一种协议。当某一个协议匹配当前连接的协议类型时，此规则生效。

协议类型通常来自流量探测（sniffing）。并非所有协议都要求入站开启 sniffing：部分协议支持路由驱动嗅探（即使入站未开启 sniffing 也可识别）。

支持的协议值、启用条件以及各协议的嗅探过程与代码执行逻辑，见 流量探测（Sniffing）。

额外语法：

  • 匹配采用前缀策略，例如 http 会匹配 http1 / http2；
  • alpn / alpn:xxx / alpn=xxx：基于嗅探写入的 attrs["alpn"]。
  • alpn：只要连接提取到任意 ALPN 即命中；
  • alpn:xxx / alpn=xxx：前缀匹配（不区分大小写），例如 alpn:h2、alpn:apns-security-v3；
  • ! 反匹配：支持 !http、!alpn:h2 等写法。匹配语义为：
    • 同时含正向与反向项时：至少命中一个正向项，且不能命中任一反向项；
    • 仅含反向项时：只要不命中反向项即命中。

示例（匹配“非 h2 ALPN”）：

json
{
  "routing": {
    "rules": [
      {
        "type": "field",
        "protocol": ["!alpn:h2"],
        "destination": "non-h2-upstream"
      }
    ]
  }
}

attrs: object

一个 json object，键名字和值皆为字符串，用于检测 HTTP 流量的属性值(由于显而易见的原因，只支持 1.0 和 1.1)。当 HTTP headers 包含所有指定的键，并且值包含指定的子字符串，则命中此规则。键大小写不敏感。值支持使用正则表达式。

同时也支持类似 h2 的伪头部 :method 和 :path 用于匹配方法和路径(尽管在 HTTP/1.1 中是不存在这些 header 的)

对于 HTTP 入站的非 CONNECT 方法，可以直接获取到attrs, 对于其他入站则需要开启 sniffing 嗅探才能获得这些值用于匹配。

例如 tls 嗅探会写入 tls_sni（1：ClientHello 包含 SNI；0：无 SNI）与 tls_version（如 1.2 / 1.3），可用于细分 TLS 版本路由。

示例：

  • 检测 HTTP GET
json
{
  "type": "field",
  "attrs": {
    ":method": "GET"
  },
  "destination": "direct"
}
  • 检测 HTTP Path
json
{
  "type": "field",
  "attrs": {
    ":path": "/test"
  },
  "destination": "direct"
}
  • 检测 Content Type
json
{
  "type": "field",
  "attrs": {
    "accept": "text/html"
  },
  "destination": "direct"
}
  • 检测 TLS 无 SNI
json
{
  "type": "field",
  "attrs": {
    "tls_sni": "^0$"
  },
  "destination": "proxy"
}
  • 检测 TLS 有 SNI
json
{
  "type": "field",
  "attrs": {
    "tls_sni": "^1$"
  },
  "destination": "direct"
}
  • 检测 TLS 1.3
json
{
  "type": "field",
  "attrs": {
    "tls_version": "^1\\.3$"
  },
  "destination": "direct"
}

process: [string]

如果连接来自本机，匹配其进程。如果不来自本机则直接视作匹配失败。仅支持 Windows 和 Linux.

该选项为一个数组，数组内每一项有三种匹配模式。

  1. 不包含斜杠，匹配进程名字。
  2. 包含斜杠，不以斜杠结尾，匹配绝对路径。
  3. 包含斜杠，以斜杠结尾，匹配文件夹，该文件夹下的进程都视为命中。

注：

  • 所有选项均大小写敏感。
  • Windows 上使用反斜杠 \ 表示路径，这里统一要求使用普通斜杠 /，如：C:/Windows/System32/curl.exe，因为反斜杠在 json 中会被视作转义符，使用不便（除非你选择把出现的反斜杠写两遍，如果这么做也可以正常识别）。
  • 使用进程名匹配时核心会自动删去 .exe 后缀，同样的 ["curl"] 可以在 Linux 和 Windows 上都命中 curl，使用绝对路径时仍不能忽略 .exe 后缀。

特殊语法糖

  • self/ 用于匹配当前核心进程，对于避免回环路由非常有用。
  • xray/ 会被替换为当前核心所在的绝对路径，将会命中所有从该二进制启动的 Xray 进程。

destination: string

路由目标，指向一个 outbound 或 balancer 的标识。

兼容字段：outboundTag / balancerTag 仍可用，解析顺序为 destination → outboundTag → balancerTag。

如果三者均未设置，则必须填写 ruleTag（用于规则链标记）。

ruleTag: string

可选，用于标识这条规则的名字，并可在规则链中被 requireRuleTag 依赖。

如果设置，则命中该条规则时会在 Info 等级输出相关信息，用于调试路由具体命中了哪条规则。

规则标记语法：

  • ruleTag 以 + 开头时，会在匹配后标记路由链，后续仅处理包含 requireRuleTag 的规则；
  • ruleTag 不允许以 ! 开头（! 用于 requireRuleTag 的排除语义）。
  • 若设置 ruleTag，同一份配置中应保持唯一（重复会导致启动失败）。

requireRuleTag: [string]

依赖先前规则命中的 ruleTag，支持排除语义：

  • ["tagA"]：需要命中过 tagA
  • ["tagA", "tagB"]：任意一个命中即可
  • ["!tagB"]：要求未命中过 tagB
  • 混合使用：["tagA", "!tagB"]

reLookup: bool

当为 true 且路由目标为域名时，在出站前重新解析该域名并用于后续 IP 规则与实际连接。

负载均衡 ​

负载均衡配置详见 负载均衡（Balancer）。

规则链示例（ruleTag / requireRuleTag） ​

json
{
  "routing": {
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:google"],
        "ruleTag": "mark-google"
      },
      {
        "type": "field",
        "domain": ["geosite:openai"],
        "ruleTag": "+mark-openai"
      },
      {
        "type": "field",
        "requireRuleTag": ["mark-openai", "!blocked"],
        "destination": "direct",
        "ruleTag": "final"
      },
      {
        "type": "field",
        "requireRuleTag": ["!final"],
        "destination": "proxy"
      }
    ]
  }
}

说明：

  • 无 destination 的规则仅用于标记 ruleTag；
  • +ruleTag 命中后仅继续评估带 requireRuleTag 的规则；
  • requireRuleTag 支持 !tag 反向条件。

预定义域名列表 ​

此列表预置于每一个 Xray 的安装包中，文件名为 geosite.dat。这个文件包含了一些常见的域名，使用方式：geosite:filename，如 geosite:google 表示对文件内符合 google 内包含的域名，进行路由筛选或 DNS 筛选。

常见的域名有：

  • category-ads：包含了常见的广告域名。
  • category-ads-all：包含了常见的广告域名，以及广告提供商的域名。
  • cn：相当于 geolocation-cn 和 tld-cn 的合集。
  • apple：包含了 Apple 旗下绝大部分域名。
  • google：包含了 Google 旗下绝大部分域名。
  • microsoft：包含了 Microsoft 旗下绝大部分域名。
  • facebook：包含了 Facebook 旗下绝大部分域名。
  • twitter：包含了 Twitter 旗下绝大部分域名。
  • telegram：包含了 Telegram 旗下绝大部分域名。
  • geolocation-cn：包含了常见的大陆站点域名。
  • geolocation-!cn：包含了常见的非大陆站点域名。
  • tld-cn：包含了 CNNIC 管理的用于中国大陆的顶级域名，如以 .cn、.中国 结尾的域名。
  • tld-!cn：包含了非中国大陆使用的顶级域名，如以 .tw（台湾）、.jp（日本）、.sg（新加坡）、.us（美国）.ca（加拿大）等结尾的域名。

你也可以在这里查看完整的域名列表 Domain list community。

贡献者 (1)

根据 CC-BY-SA 4.0 许可协议授权

版权所有 © 2020-至今 Project X 社区