机场订阅是什么:订阅、节点与客户端各管一段

求助帖里出现频率最高的一句话是「我的订阅连不上」。这句话把三样东西揉在了一起:订阅是一份清单,节点是真正在跑流量的服务器,客户端是设备上那个负责把清单变成连接的软件。三者中任何一环出问题,表面现象都可能是「连不上」,但处理方式完全不同——清单取不回来时,再怎么切换节点都没有意义,因为客户端里根本还没有节点这个对象。

把职责边界画清楚,是新手期回报最高的一次投入。之后遇到的绝大多数现象,都可以先归到某一段上,再决定要不要动手。

一条订阅链接里究竟装了什么?#

订阅链接不是节点,它是一个普通的 HTTPS 网址,访问它会返回一段文本。这段文本里逐条写着每个节点的地址、端口、加密方式、传输方式和名字——也就是客户端建立连接所需要的全部参数。你可以把它理解成通讯录:通讯录本身不会打电话,但没有它你也拨不出号。

不同格式的清单封装方式不一样。有的是一整段 Base64 编码的纯文本,解开之后一行一个节点;有的直接就是一份 YAML 配置,除了节点还带着分组和规则。内容层面它们描述的是同一批服务器。

顺带说一句:节点名不是装饰,地区、编号、倍率和用途标签都写在里面,学会在连接前先读名字,可以省掉挨个点测的时间,这部分展开在怎么读懂节点名里的地区与倍率标记。

客户端更新订阅的时候在做什么动作?#

「更新订阅」这个按钮背后是一次很普通的网络请求,拆开看只有五步:

1. 客户端向订阅地址发起一次 HTTP GET 请求,并在请求头里附上自己的标识(User-Agent)。带这个标识是为了让服务端知道来的是哪一类客户端。
2. 服务端根据这个标识决定返回哪种格式。同一条链接,通用客户端来取会拿到 Base64 清单,Clash 类客户端来取可能直接拿到 YAML,这是服务端做的判断,不是链接不同。
3. 服务端顺便在响应头里塞进流量信息,包括已用上传、已用下载、总额度和到期时间戳。客户端界面上那条流量进度条,数据就来自这里。
4. 客户端解码并解析这份文本,把每个节点变成本地配置里的一条记录,同时保留你自己建立的规则和分组。
5. 旧节点被替换。服务端这次没给的节点会从列表里消失,这一步是覆盖而不是合并。

一次请求大致长这样,以下是结构示例,地址与数值均为占位:

GET /api/v1/client/subscribe?token=YOUR_TOKEN HTTP/1.1
Host: example.invalid
User-Agent: clash-verge/2.0

服务端返回的头部里通常有这么一行,也是结构示例:

subscription-userinfo: upload=0; download=32212254720; total=107374182400; expire=1767225600

单位是字节,时间是 Unix 时间戳。客户端把它换算成「已用 30GB / 共 100GB,某月某日到期」显示给你。所以流量数字对不上时,该怀疑的是服务端的统计口径,而不是客户端算错了。

为什么节点列表会自己变多变少?#

因为清单是每次现取的,不是一次性下发给你的固定资产。服务端在这几种情况下会改动清单内容:

• 某台服务器被封或需要维护,运维把它从清单里摘掉,你刷新后就少一条;
• 新上了线路或新增落地,清单里多出几条,名字里往往带着新地区或新标签;
• 套餐等级不同,能看到的节点组不同,升级或降级套餐后清单会整体变化;
• 临时活动节点有存续期,活动结束后自动消失。

节点数量的正常波动和「订阅出问题」是两回事。前者是几条节点增减,后者是一次都拉不到或列表整个变空。如果刷新后节点归零,按订阅更新失败的定位方法走,而不是反复点更新。

订阅链接等于账号凭证:泄露之后会发生什么?#

这条链接里带着一个 token,服务端只认这个 token,不会再要求输入密码。也就是说,链接本身就是凭证——谁拿到它,谁就能取回你的全部节点清单,顺带从响应头里看到你的流量额度和到期时间。

后果是双重的:一是别人的连接会占用你套餐里的同时在线设备数和流量;二是你在服务商那边的使用记录会混入他人的行为。技术机制层面就这么简单,至于隐私影响的边界在哪、发现泄露后该怎么处理,单独写在机场安全吗:服务商看得到什么。

订阅需要每天更新吗,多久拉一次比较合理?#

不需要盯着刷。更新的唯一作用是同步清单,清单没变时,更新一百次结果也一样。

高频自动更新还有个副作用:部分服务商对订阅接口有请求频率限制,短时间内反复拉取可能被临时拒绝,表现出来又是一次「订阅失效」的假象。

同一条订阅在不同客户端里表现不同,是什么原因?#

因为服务端按 User-Agent 发的内容本来就不同,加上各客户端支持的协议范围不一样,同一份清单落到不同软件里就会被裁掉一部分。

结论是:节点数量少了不一定是机场的问题,先换一个协议支持更全的客户端试一次。各客户端的配置差异在客户端教程栏目里按软件分开写了。

订阅转换是在解决什么问题?#

它解决的是格式不兼容:你的客户端只认某种配置格式,而机场给的清单是另一种。转换服务把清单取回来,重新封装成目标格式,再输出一条新链接给你。

代价要说清楚。转换过程中,那台转换服务器必然完整看到你的订阅内容——所有节点地址、端口和凭据。用公开的第三方转换服务,等于把这份清单交给了一个你不了解的第三方。

优先用机场自己提供的多格式订阅链接。确实需要转换时,选择自建或来源可核实的服务,不要把主力订阅丢进随手搜到的转换页面。

重置订阅链接之后,旧链接为什么立刻作废?#

因为重置的动作就是在服务端换掉那个 token。服务端拿到请求后只做一件事:按 token 查是哪个账户、该发哪些节点。旧 token 在数据库里已经不对应任何账户,请求会被直接拒绝,和链接格式对不对没有关系。

所以重置有个必然的连带后果:所有设备上的旧链接同时失效,需要逐台重新导入。这也是为什么重置不该随手做,而应该在确认链接可能已经泄露、或者流量出现无法解释的消耗时才执行。

小结#

订阅是清单,客户端是执行者,节点是出口,三者各管一段,故障也就分在三段上。看到问题先判断它落在哪一段:列表拉不回来是订阅段,列表正常但全红是节点或本地网络段,能连上却打不开网页是客户端的分流与代理设置段。这个分段习惯建立起来之后,多数排查会在第二步就收敛。订阅链接要当密码看待,不共享、不粘贴进来路不明的转换页面,发现异常再重置也不迟。