export http_proxy不总是生效，因wget、git、go等工具对代理变量大小写敏感或需单独配置，且ssh、docker、npm等完全忽略该变量，须按工具规则分别设置。
为什么 export http_proxy 不总是生效
终端里执行 export http_proxy="http://127.0.0.1:8080" 后，curl 可能走代理，但 wget、git 或某些 Go/Python 工具却直连——因为它们不读取 http_proxy 环境变量，或优先级被覆盖。
-
wget默认只认http_proxy，但若配置了~/.wgetrc里的http_proxy行，会以配置文件为准 -
git需显式设置：git config --global http.proxy "http://127.0.0.1:8080" - Go 程序（如
go get）读HTTP_PROXY（全大写），小写变量无效 - 部分 Rust/Cargo 工具依赖
https_proxy，漏设会导致 HTTPS 请求失败
如何让 proxy 环境变量真正“全局”生效
仅在当前 shell 执行 export 是临时的；要持久化，必须写入 shell 初始化文件，但要注意不同 shell 的加载路径差异。
Linux Ai Server
下载
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
- 对 Bash：追加到
~/.bashrc（交互式非登录 shell）或~/.bash_profile（登录 shell），推荐统一写~/.bashrc并确保~/.bash_profile有source ~/.bashrc - 对 Zsh：写入
~/.zshrc，Zsh 默认不读~/.bashrc - 务必同时设置大小写变体：
export HTTP_PROXY="http://127.0.0.1:8080"和export http_proxy="http://127.0.0.1:8080"，避免工具因大小写敏感失效 - 记得设
NO_PROXY（或no_proxy）跳过内网和本地地址，例如：export NO_PROXY="localhost,127.0.0.1,.internal.example.com"
哪些命令会忽略 proxy 环境变量
不是所有命令都遵守 http_proxy。典型例外包括：
-
ssh：完全不读 proxy 变量，需改~/.ssh/config配ProxyCommand nc -X connect -x 127.0.0.1:8080 %h %p -
docker pull：Docker 守护进程不继承用户 shell 环境，须在/etc/docker/daemon.json中配置proxies字段 -
npm install：使用npm config set proxy http://127.0.0.1:8080，环境变量仅对部分 npm 子命令有效 - systemd 服务（如自启的脚本）：运行在独立环境中，
systemctl --user set-environment或服务 unit 文件中用Environment=显式声明
验证代理是否真正生效的可靠方式
别只信 echo $http_proxy，要测真实流量走向：
- 用
curl -v http://httpbin.org/ip 2>&1 | grep "Connected to"，看输出里是连到了代理地址还是目标 IP - 启动本地代理（如
mitmproxy或cntlm），再发请求，直接在代理日志里确认是否收到 - 对 HTTPS 请求，注意有些工具（如
curl）会把 CONNECT 请求发给 proxy，但证书校验失败时静默降级——加-k或检查curl -v https://httpbin.org/ip的 TLS 握手日志 - 临时关闭代理服务，观察命令是否报 “Connection refused” 而非超时，可区分是代理未触发还是代理本身挂了
http:// 必须写全）、NO_PROXY 域名匹配逻辑（点号开头才匹配子域）这些细节稍错一点，就悄无声息地退化为直连。
