为什么 systemd 服务用不到终端里的代理设置
将代理配置放进 systemd 服务的实际环境，而不是指望在终端 export 变量就能重配正在运行的进程。
先检查出错的服务，不要只在终端继续导出变量。systemctl cat example.service 会显示它的单元文件和补充配置；检查是否有 EnvironmentFile、其他覆盖配置或应用自身的代理设置。包含凭据的输出应只在本地查看。
如果应用读取 HTTP 代理环境变量，可通过服务的补充配置提供：
[Service]
Environment="HTTP_PROXY=http://203.0.113.10:8080"
Environment="HTTPS_PROXY=http://203.0.113.10:8080"替换示例文档中的端点，并使用应用支持的变量名。如果服务获准使用公共 HTTP 代理，可在HTTP 代理列表中寻找候选地址。自行配置代理的客户端可能忽略这些输入。同时确认这确实是要修改的系统服务：用户服务使用不同的管理器和环境，修改同名或近似名称的系统单元无法修复它。
编辑目标单元或补充配置后，重新加载定义，并在允许中断工作负载时重启该服务：
sudo systemctl daemon-reload
sudo systemctl restart example.service仅运行 daemon-reload 不会替换现有进程的环境。重启才会启动新进程；shell 中导出变量只影响该 shell 及其随后启动的子进程。
服务收到预期 URL 后，应沿着它实际报告的错误排查。其账号可能无权读取 CA 文件，其网络命名空间可能无法连接监听端，也可能是代理拒绝了请求。这些是后续检查项，不是继续修改无关 shell 配置文件的理由。