企查查代理访问方案

背景与目标

澳洲的 Windows 主机需要访问中国大陆的企查查网站（qcc.com）。由于企查查对海外 IP 存在访问限制/区别对待，且澳洲到阿里云中国大陆的直连线路质量差，采用两跳代理链路，以中国大陆 IP 作为最终出口访问。

约束条件：澳洲 Windows 主机上不允许安装任何第三方 VPN/代理软件，只能修改浏览器/系统的代理设置。

网络架构

澳洲 Windows 浏览器
   │  PAC 脚本（仅 qcc.com 走代理，其余直连）
   ▼
东京服务器 47.74.*.*:自定义端口   ← gost HTTP 代理入口，带 Basic 认证
   │  relay+tls 加密链路（阿里骨干网，约 61ms）
   ▼
北京 ECS 39.107.*.*              ← gost 出口，安全组仅放行东京服务器 IP
   ▼
企查查（以北京数据中心 IP 访问）

节点	IP	角色
澳洲 Windows 主机	（待确认是否固定 IP）	客户端，仅配置浏览器代理
东京服务器（当前服务器）	47.74..	代理入口 + 中继，托管 PAC 文件
北京 ECS（华北2）	39.107..	代理出口，大陆 IP

关键设计决策

1. 协议选 HTTP 代理（CONNECT 隧道），不用 SOCKS5
   企查查是 HTTPS 站点，HTTP 代理通过 CONNECT 透传 TLS，无需解密。Chrome/Edge/Firefox 均不支持带认证的 SOCKS5，但原生支持 HTTP 代理的 Basic 认证（浏览器弹框输入账号密码）。

2. 用 PAC 脚本而非全局代理
   PAC 仅将 *.qcc.com 及相关资源域名导向代理，其余流量直连，避免澳洲主机全部流量绕道中国。浏览器端只需填一个”自动配置脚本 URL”。

3. 两跳之间使用 gost relay+tls 加密
   东京 → 北京之间不暴露明文代理协议，更安全也更抗干扰。

4. 安全收口

   • 东京入口：Basic 认证（长随机密码）+ 非常规端口；若澳洲主机 IP 固定，防火墙额外限源。
   • 北京 ECS：安全组仅放行东京服务器 IP（47.74..），对公网完全不可见。
   • 严禁形成开放代理，否则可能被扫描滥用，导致阿里云封端口/停机。

前期验证（已完成）

检查项	结果	状态
当前服务器位置与出口 IP	阿里云国际·东京，47.74..	✅
东京 → 北京 ECS 链路质量	30 包 0% 丢包，平均 61ms，抖动 1.3ms	✅
端到端延迟预估	澳洲→东京→北京约 170~220ms，浏览可用	✅

实施步骤

步骤 1：北京 ECS 验证企查查可访问性 —— ✅ 已完成（2026-07-08）

在 ECS 上直接请求企查查，确认该 IP 未被风控拦截，避免后续白做。

curl -sI --max-time 10 https://www.qcc.com/ | head -5

预期：返回 HTTP 200 或正常跳转（301/302 到登录页也算正常），而非 403/连接被重置。

• 执行结果：✅ 通过。
  • SSH 登录 ECS 成功，确认出口 IP = 39.107.*.*（China Beijing），系统 Alibaba Cloud Linux 3。
  • https://www.qcc.com/ 返回 HTTP/2 200，server: Tengine，内容 38774 字节。
  • 页面标题正常：企查查 - 查企业_查老板_查风险_企业信息查询系统。
  • 验证码/风控关键词命中 0，企查查相关关键词命中 64，确认为真实首页而非拦截页。
  • 结论：该大陆 IP 访问企查查首页无风控拦截，方案前提成立。可继续搭链路。

步骤 2：北京 ECS 部署 gost 出口 —— ✅ 已完成（2026-07-08）

1. 下载安装 gost（v3）。
2. 启动 relay+tls 监听（端口 18443，带认证）。
3. 配置 systemd 服务实现开机自启与守护。
4. 阿里云安全组：入方向仅放行 47.74.*.*/32 访问 18443 端口。

• 执行结果：✅ 完成。
  • gost 版本 v3.2.6。因 ECS 直连 GitHub 下载超时，改为东京服务器下载后经骨干网 scp 至 ECS，安装到 /usr/local/bin/gost。
  • 中继凭据（东京↔北京链路，relay+tls 认证）：
    • RELAY_USER = rly_77b4fc
    • RELAY_PASS = xxxxxxx
    • 暂存于东京 /tmp/relay_creds.txt。
  • systemd 服务 gost-exit.service：ExecStart=/usr/local/bin/gost -L "relay+tls://rly_77b4fc:xxxxxxx@:18443"，状态 active、已 enabled 开机自启。
  • 日志确认：listening on [::]:18443/tcp，无报错。
  • 安全组 18443 已由用户在阿里云控制台放行东京 IP。ECS 主机防火墙 firewalld/iptables 均无规则（inactive/空）。

步骤 3：东京服务器部署 gost 入口 —— ✅ 已完成（2026-07-08）

1. 下载安装 gost（v3）。
2. 启动 HTTP 代理入口，带认证，转发到北京出口（端口 28080）。
3. 配置 systemd 服务。
4. 防火墙/安全组放行 28080；若澳洲 IP 固定则限源。

• 执行结果：✅ 完成（服务运行中）。
  • 东京当前用户为 claus，无 root/免密 sudo，故 gost 装于 ~/.local/bin/gost，以 user 级 systemd 运行。
  • 浏览器代理凭据（Basic 认证）：
    • PROXY_USER = qcc_1a01
    • PROXY_PASS = xxxxxxx2
    • 暂存于东京 /tmp/proxy_creds.txt。
  • 服务 ~/.config/systemd/user/gost-entry.service：
    ExecStart=%h/.local/bin/gost -L "http://qcc_1a01:xxxxxxx2@:28080" -F "relay+tls://rly_77b4fc:xxxxxxx@39.107.*.*:18443"
    状态 active，监听 *:28080。
  • ⚠️ 保活待办：Linger=no，该 user 服务在 claus 登出或服务器重启后不会自动拉起。需 root 执行 loginctl enable-linger claus 才能开机常驻（见步骤 7 遗留项）。
  • 东京安全组需放行入方向 28080（供澳洲主机访问）；若澳洲主机 IP 固定，建议限源。

步骤 4：东京服务器托管 PAC 文件 —— ✅ 已完成（2026-07-08）

1. PAC 文件已编写完成 ~/pac/qcc.pac（抓包确认企查查同时使用 qcc.com 与 qichacha.com 两组域名，均已覆盖）：

   function FindProxyForURL(url, host) {
       if (dnsDomainIs(host, ".qcc.com") || host === "qcc.com" ||
           dnsDomainIs(host, ".qichacha.com") || host === "qichacha.com") {
           return "PROXY 47.74.*.*:28080";
       }
       return "DIRECT";
   }

2. 托管服务 unit 已创建 ~/.config/systemd/user/qcc-pac.service（python3 http.server 监听 28081），
   PAC URL 将为 http://47.74.*.*:28081/qcc.pac。

• 执行结果：✅ 完成（用户已授权公网暴露）。
  • 服务 qcc-pac.service（user systemd）状态 active，监听 0.0.0.0:28081。
  • 本地取 PAC 内容正确。
  • PAC URL：http://47.74.*.*:28081/qcc.pac（澳洲浏览器填这个）。
  • ⚠️ 同样受 Linger=no 影响，重启后需 linger 才能自动拉起。
  • 东京安全组需放行入方向 28081。

步骤 5：链路端到端自测（东京侧模拟） —— ✅ 已完成（2026-07-08）

在东京服务器上通过入口代理请求企查查，验证整条链路：

curl -sI --max-time 15 -x "http://<user>:<password>@127.0.0.1:28080" https://www.qcc.com/ | head -5

预期：返回正常响应，且出口 IP 为 39.107..（可通过代理访问 ipinfo.io 确认）。

• 执行结果：✅ 全部通过。
  • 经代理查出口 IP：China Beijing 39.107.*.* —— 确认最终以北京大陆 IP 出网。
  • 经代理访问 https://www.qcc.com/：HTTP/1.1 200 Connection established + Proxy-Agent: gost/3.0 + HTTP/2 200，链路完整。
  • 安全验证：无认证 / 错误密码访问均被拒（状态 000，隧道未建立），确认非开放代理。

步骤 6：澳洲 Windows 浏览器配置 —— 🔲 待用户在 Windows 操作

方式 A：系统级 PAC（Chrome/Edge 都生效，推荐）

1. 设置 → 网络和 Internet → 代理 → “使用设置脚本” 打开。
2. 脚本地址填：http://47.74.*.*:28081/qcc.pac → 保存。
3. 浏览器访问 https://www.qcc.com/，首次弹认证框：
   • 用户名 qcc_1a01
   • 密码 xxxxxxx2
   • 可勾选”记住”。
4. 验证：企查查正常打开；访问 google.com 等仍走直连（不受影响）。

方式 B：仅 Firefox（不改系统，只影响 Firefox）

• 设置 → 网络设置 → “自动代理配置 URL(PAC)”，填同一个 PAC URL。

• 执行结果：（待用户操作后填写）

前置条件（东京安全组）—— ✅ 已放行并验证（2026-07-08）

澳洲主机要能连到东京，必须放行东京服务器（47.74..）入方向两个端口：

• 28080/tcp —— 代理入口（必需）
• 28081/tcp —— PAC 文件（必需）
• 若澳洲主机为固定公网 IP，强烈建议把这两条规则的源限定为该 IP。

公网方向连通性验证（以北京 ECS 作为外部节点回连东京公网 IP，与澳洲走同一入站路径）：

• 28080 / 28081 端口公网均可达 ✅
• 公网取 PAC http://47.74.*.*:28081/qcc.pac 成功 ✅
• 经东京公网代理访问企查查：HTTP/2 200 ✅
• 经东京公网代理出口 IP：39.107.*.*（中国 北京 阿里云），与北京本地直连一致 ✅
• 结论：服务器端全链路对外可用，澳洲主机配好浏览器即可访问。

步骤 7：重启保活（linger）—— ✅ 已完成（2026-07-08）

东京两个 user systemd 服务（gost-entry、qcc-pac）在 claus 登出或服务器重启后不会自动拉起，
需以 root 执行一次 loginctl enable-linger claus。

• 执行结果：✅ 完成（用户已执行）。核实：Linger=yes；gost-entry、qcc-pac 均 enabled + active。
  东京重启后自动拉起；北京 gost-exit 为系统级 systemd，已 enabled，一并具备重启自恢复。

遗留风险与备注

风险项	说明	应对
企查查风控	数据中心 IP 可能触发验证码/频率限制；大部分数据需登录账号	步骤 1 先验证；代理只解决 IP 归属地问题，不绕过账号/反爬机制
阿里云合规	大陆 ECS 上跑代理属敏感操作	本场景为入境访问境内网站（非翻墙出境）；必须带认证 + 限源，不做开放代理
澳洲主机 IP 是否固定	影响东京入口能否做源 IP 白名单	待确认；动态 IP 则依赖强密码 + 非常规端口
代理认证弹框	浏览器每次会话首次访问会弹认证框	属预期行为；浏览器可记住凭据

知识点

gost

gost(全称 GO Simple Tunnel)是一个用 Go 语言写的开源网络隧道/代理工具。你可以把它理解成一把”网络流量的瑞士军刀”——一个单独的可执行文件,不依赖任何其他环境,就能同时扮演代理服务器和流量转发器两种角色。

• 项目地址:github.com/go-gost/gost,我们装的是最新的 v3.2.6。
• 单文件、跨平台、无依赖:就是我们下载的那个 9MB 的二进制,丢到服务器上 chmod +x 就能跑,不用装运行时、不用配一堆依赖。这也是为什么它特别适合放在服务器上做中转。

它解决什么问题

一句话:让流量按你指定的路径和协议走。它能做的事很多:

• 当各种代理服务器:HTTP 代理、SOCKS5、Shadowsocks 等;
• 做端口转发、流量中继;
• 把流量套上加密隧道(TLS、WebSocket、gRPC 等)再传输;
• 多级串联(chain),让流量依次经过多个节点。

在我们方案里 gost 的两个角色

我们正是用了它”代理 + 加密中继 + 多级串联”这几个能力,在两台服务器上各跑一个 gost:

北京 ECS(出口角色)
gost -L “relay+tls://用户名:密码@:18443”

• -L = Listen,表示”在本机监听、对外提供服务”。
• relay+tls = 用 TLS 加密的中继协议监听 18443 端口。
• 它接收东京转发过来的流量,然后以北京本地 IP 替你去访问企查查,再把结果原路返回。这就是”大陆 IP 出口”的来源。

东京服务器(入口角色)
gost -L “http://用户名:密码@:28080” -F “relay+tls://用户名:密码@39.107..:18443”

• -L http://...@:28080:在东京监听一个带认证的 HTTP 代理,这是浏览器直接连的入口。
• -F = Forward,表示”把收到的流量转发给下一跳”。
• -F relay+tls://…北京:18443:把流量through 加密隧道甩给北京的 gost。

所以整条链路的本质就是:

浏览器 --HTTP代理--> 东京gost --relay+tls加密隧道--> 北京gost --明文--> 企查查
                    (入口/-L)                    (出口/-L)
                        └────────── -F 转发 ─────────┘

为什么选它,而不是别的

对比常见替代品,gost 在我们这个场景有几个恰好的优势:

需求	gost 的对应能力
浏览器零安装	提供标准 HTTP 代理,浏览器/PAC 原生支持,客户端什么都不用装
两台服务器串联	-L 和 -F 组合,一条命令就搭好中继链
两服务器间要加密	relay+tls 直接给隧道套 TLS,不暴露明文代理协议
防止被人白嫖	协议里内置账号密码认证(用户名:密码@)
部署简单	单个二进制,配 systemd 就能常驻

如果换成传统方案,你可能要 Squid(HTTP 代理)+ stunnel(加密)+ 一堆配置文件才能拼出同样的效果;gost 一个程序、两条命令就搞定了,这是它”Simple”这个名字的由来。

一个小提醒

gost 功能强大,既能用于我们这种”访问境内网站的合规中转”,也常被用于翻墙等场景,所以它在某些环境里比较敏感。我们的用法是入境访问境内合法网站 + 全程认证 + 安全组限源,性质上是干净的,这点之前也在方案风险里注明过。

想深入的话,它还支持负载均衡、多级跳板、UDP 转发、准入控制等更复杂的玩法,但你这个场景用到的就是上面这些核心能力,已经够用且稳定了。

PAC

PAC(Proxy Auto-Config,代理自动配置)本质上就是一小段 JavaScript 代码,浏览器每次要访问一个网址时,都会先运行这段代码问它:”这个地址,我该走代理,还是直连?” 代码返回答案,浏览器照做。
所以 PAC 不是什么复杂系统,它就是一个决策函数。浏览器把决定”走不走代理”这件事外包给了这个函数。

我们写的 PAC 长这样

function FindProxyForURL(url, host) {
    if (dnsDomainIs(host, ".qcc.com") || host === "qcc.com" ||
        dnsDomainIs(host, ".qichacha.com") || host === "qichacha.com") {
        return "PROXY 47.74.*.*:28080";
    }
    return "DIRECT";
}

逐行拆解:

• function FindProxyForURL(url, host) —— 这个函数名是固定规定的,浏览器就认这个名字。每次访问网页,浏览器自动调用它,把完整网址传给 url、把域名部分传给 host。
• dnsDomainIs(host, “.qcc.com”) —— 这是 PAC 内置的一个判断函数,意思是”这个域名是不是属于 qcc.com”。比如 www.qcc.com、m.qcc.com 都会命中。
• return “PROXY 47.74..:28080” —— 如果是企查查的域名,就告诉浏览器”走这个代理”(也就是我们东京的入口)。
• return “DIRECT” —— 其它所有网址,返回”直连”,浏览器正常访问,完全不经过代理。

翻译成大白话就是:”如果你要访问的是企查查或企查查的资源域名,就走东京代理;否则一律直连。”

为什么必须用 PAC,而不是直接设个代理

这是你这个需求的要害。Windows 系统代理有两种设法:

方式	效果
固定代理(填一个代理IP)	该主机所有网站流量都走代理。访问Google、本地澳洲网站也全部绕道东京→北京,又慢又浪费流量
PAC 脚本	按域名精准分流,只有企查查走代理,其余全部直连,互不影响

你的场景是”澳洲主机平时正常上网,只有访问企查查时才需要走大陆出口”——这正是 PAC 存在的意义:精细化分流。固定代理会把整台机器的上网体验都拖下水,PAC 则像一个只对企查查生效的开关。
PAC 是怎么送到浏览器手里的
PAC 是段代码,得让浏览器能拿到。有两种交付方式:

1. 托管成一个 URL(我们用的方式)——把 PAC 文件放在东京的 HTTP 服务上(28081 端口),浏览器里填这个地址:
   http://47.74.*.*:28081/qcc.pac
   浏览器启动时去这个 URL 把脚本下载下来,之后每次访问网页就本地运行它。改规则时只要改服务器上这个文件,所有客户端下次自动生效,不用逐台改。
2. 放本地文件(file:// 路径)——现代 Chrome/Edge 出于安全已基本禁用,所以我们没用。

整个配合流程串起来

在澳洲主机填好 PAC URL 后,一次访问企查查的完整过程:

浏览器要开 www.qcc.com
│
├─ 先跑 PAC:FindProxyForURL(“…qcc.com”,”www.qcc.com“)
│ → 命中 qcc.com 规则,返回 “PROXY 47.74..:28080”
│
└─ 浏览器于是把请求发给东京 gost 代理 → 北京出口 → 企查查 ✅

浏览器要开 google.com
│
├─ 先跑 PAC → 不命中任何规则,返回 “DIRECT”
│
└─ 浏览器直接连 Google,完全不经过我们的链路 ✅

几个实用补充

• 想扩展规则:如果以后发现企查查某些资源走了别的域名没被代理(比如图片打不开),只要在东京那个 PAC 文件里加一行对应域名判断,保存即可,客户端无需改动。
• PAC 语法很克制:它只有一小套内置函数(dnsDomainIs、shExpMatch、isInNet 等),够做域名/IP 段/通配符匹配,不是完整 JS 环境,不能联网、不能读文件,纯做判断。
• 调试:如果分流不符预期,可以在浏览器里看它到底走没走代理,或临时在 PAC 里改逻辑测试。

一句话总结:gost 负责”怎么把企查查流量运到大陆出口”,PAC 负责”决定哪些流量该交给 gost”,两者配合才实现了你要的”浏览器设一下、只有企查查走这条路”的效果。

东京部署gost入口我的这个账号claus没有问题吧，跟root账号比有什么不同

结论先说:用 claus 账号完全没问题,而且从安全角度看甚至比用 root 更好。 我们该处理的差异(重启保活)也已经处理掉了。下面讲清楚为什么,以及和 root 到底差在哪。
为什么 claus 够用
东京入口这个 gost 进程实际需要的权限很少,claus 全都满足:

• 监听端口:我们用的是 28080 和 28081,都是 1024 以上的高位端口。Linux 只有 1024 以下的端口(如 80、443)才需要 root 才能绑定,高位端口普通用户随便用。
• 运行程序:gost 二进制放在 ~/.local/bin/,claus 自己的目录,能读能执行。
• 常驻/开机自启:用 user 级 systemd + linger 实现,不需要 root。这个我们已经配好了(Linger=yes)。

所以这个进程从头到尾没有一件事需要 root 权限。

root 和 claus 的具体区别

在我们这个场景里,差异主要是三点,而且都不影响功能:

方面	root	claus(我们用的)	对我们有影响吗
能绑的端口	任意,包括 80/443	只能 1024 以上	无。我们用28080/28081
程序安装位置	/usr/local/bin(全系统)	~/.local/bin(仅本用户)	无。运行效果完全一样
开机自启方式	系统级systemd,天然随开机启动	user 级 systemd,需 enable-linger才随开机启动	已处理(linger 已开)
进程权限范围	整台机器的最高权限	只有 claus 这个用户的权限	这点 claus 反而更安全

关键:非 root 其实是优点,不是缺点

这是”最小权限原则”——只给程序完成任务所需的最低权限。

设想一个极端情况:如果 gost 有漏洞被人利用了(任何联网服务都有这种理论风险),那么:

• 如果它以 root 跑:攻击者拿到的是整台服务器的最高权限,可以读所有文件、装后门、改系统配置,基本等于服务器沦陷。
• 如果它以 claus 跑(我们的情况):攻击者最多只能拿到 claus 这个普通用户的权限,碰不了系统文件、动不了别的用户、改不了系统配置,破坏面被牢牢限制住。

所以专业运维里,能用普通用户跑的服务就绝不用 root 跑。我们这个部署恰好符合这个最佳实践。

唯一要记住的一点

用 claus 跑的代价就是那个 linger ——普通用户的服务默认在用户登出后会被系统关掉,必须显式开启 linger 才能让它”脱离登录会话、随开机常驻”。这一步你已经做了,Linger=yes 我也核实过,所以这个唯一的注意点已经闭环。

对比之下,北京出口那个 gost-exit 我是用 root 装的系统级服务(因为你给的是 root 账号),它天然开机自启、不需要 linger。两边方式不同,但最终都达到了”开机自动运行、稳定常驻”的效果,而东京用 claus 这条路在安全性上还更稳妥一些。

一句话:claus 账号跑这个入口,功能上毫无短板,安全上还占优,你可以放心。

这么看来唯一缺点就是程序安在了本用户的目录下，这算缺点吗

装在用户目录”看起来像缺点”的地方

传统观念里,系统服务的程序”应该”放在 /usr/local/bin 这种全系统共享目录,理由通常是:

• 全用户可用:任何用户都能执行它;
• 位置规范统一:符合运维习惯,别人接手时知道去哪找;
• 跟着系统级 systemd:管理入口统一。

装在 ~/.local/bin(claus 家目录下)就没有这几条——只有 claus 能用、位置”非主流”。所以表面看像个缺点。

为什么在你这里其实无所谓

上面那几条”好处”,你这个部署一条都用不上:

• “全用户可用”你不需要。这个 gost 入口就是 claus 一个用户在跑、一个服务在用,压根没有”别的用户也要执行它”的需求。反而”只有 claus 能碰”更符合最小权限。
• “位置统一”影响很小。它归属于 claus 的 user systemd 服务,ExecStart 里写的是绝对路径(%h/.local/bin/gost),systemd 精确知道去哪找,不存在”找不到”的问题。真正要注意的是在文档里记清楚位置——这点我们的方案文档已经写明了。
• “跟系统 systemd 走”你用 user systemd + linger 已经等效实现了开机常驻。

唯一算得上”代价”的两点(都很轻)

要挑毛病的话,只有这么两条,而且都不痛:

1. 换个人用别的账号登录时,不能直接敲 gost。因为它不在系统 PATH 里。但你根本不需要手敲——它由 systemd 托管自动运行。这只在”别人想手动调试”时才有一点点不便。
2. 绑定在 claus 这个用户身上。哪天这台服务器要停用 claus 用户、或迁移账号,得连带迁移 ~/.local/bin/gost、~/.config/systemd/user/ 下的服务文件和 PAC 目录。但这也就是几个文件的事,方案文档里路径都记着。

换个角度看,它还有优点

装在用户目录其实带来一个附加好处:整套东西是”自包含”的,全在 claus 家目录里——二进制、服务定义、PAC 文件都在 ~ 下面。要备份、迁移、或者彻底清理,直接围绕这个家目录操作即可,不会在 /usr、/etc 等系统目录里散落文件,不”污染”系统。这在多人共用的服务器上反而是干净的做法。

如果你确实想要”更标准”的做法

真要追求规范,把它挪成 root 的系统级部署也就几步:root 把二进制装到 /usr/local/bin、服务文件放到 /etc/systemd/system/、去掉对 linger 的依赖。功能完全一样,只是更符合传统运维习惯、也不再绑定 claus 用户。

但我的建议是:没必要动。现在这套跑得稳、验证全绿、安全性还更好,”装在用户目录”带来的那点不规范,远不值得为它拿 root 去重做一遍、还把进程权限升高。能用普通用户跑稳的服务,不必为了”看着标准”而改成 root。

一句话:这不算缺点,是一个中性的部署选择,在你的单用户场景下几乎零影响,还附带了”自包含、好迁移、更安全”的好处。

linger

“linger”这个词本身是英文“逗留、停留、徘徊”的意思,在 Linux systemd 里它就取了这个字面含义的引申:让用户的后台服务在你退出登录后,依然”逗留”在系统里继续运行,而不是被清走。 我给你讲清楚它到底在管什么。

要先理解一件事:普通用户的服务默认”人走服务停”

systemd(Linux 的服务管理器)管理服务分两个层级:

• 系统级服务(root 的,/etc/systemd/system/):随开机启动,和任何人是否登录无关。北京那个 gost-exit 就是这种。
• 用户级服务(systemctl –user,普通用户自己的):默认跟着你的登录会话走。

关键就在第二种。Linux 的默认逻辑是:

一个普通用户的后台进程/服务,是”属于这次登录会话”的。当你退出登录(logout)、或者服务器重启,系统认为你这个人已经离开了,就会把你名下的这些服务一并关掉。

这个设计本意是合理的——比如你 SSH 上去随手跑了个测试程序,登出时系统帮你清理掉,免得留一堆没人管的僵尸进程。

但这对我们是致命的

我们的东京入口(gost-entry)和 PAC 服务(qcc-pac)恰恰是用 claus 这个普通用户跑的 user 级服务。按默认逻辑:

• 我 SSH 登录 claus → 启动服务 → 服务在跑 ✅
• 一旦这个登录会话结束(我登出、或服务器重启)→ 系统把 claus 的服务全关掉 ❌

那澳洲主机就连不上了。这显然不行——我们要的是”7×24 常驻,不管有没有人登录”。

linger 就是解决这个的开关
loginctl enable-linger claus 这条命令,直译就是”允许 claus 逗留”。它告诉系统:

“claus 这个用户比较特殊,就算他没登录,也请你为他维持一个用户会话,让他的 user 服务一直跑着。”

所以 linger 的作用一句话概括:让普通用户的后台服务摆脱”登录会话”的束缚,变成真正的、开机即启的常驻服务——效果就跟 root 的系统级服务一样了。

为什么 root 不需要它

你可能会问:北京那个 gost-exit 也是服务,怎么没提 linger?因为它是 root 装的系统级服务,系统级服务本来就和登录无关、天然随开机启动,不存在”人走服务停”的问题。

linger 是专门用来弥补”用户级服务”这一个短板的。我们东京用普通用户 claus 部署(前面聊过,这样更安全),代价就是要手动开一次 linger 来换取常驻能力。你已经执行了,我也核实过 Linger=yes,所以这个短板已经补上,东京服务现在具备和 root 服务一样的”开机自启、稳定常驻”能力。

一句话记忆:linger = 让用户登出后,他的后台服务”继续逗留”运行的许可证。