curl和wget突然走代理是因为环境变量http_proxy等被静默设置；检查用env | grep -i proxy，注意大小写、no_proxy后缀匹配规则及systemd服务不继承用户环境。
curl 和 wget 突然走代理，但没设过代理
Linux 下很多命令（比如 curl、wget、git）会自动读取环境变量里的代理配置，哪怕你没主动设过，也可能被其他程序或 shell 初始化脚本悄悄写入。最常见的是 http_proxy、https_proxy、no_proxy 这几个变量。
检查方式很简单：env | grep -i proxy
- 如果输出里有
http_proxy=http://127.0.0.1:8080这类内容，就是它在起作用 -
no_proxy如果写成no_proxy=127.0.0.1,localhost是对的，但写成no_proxy=localhost就不覆盖127.0.0.1—— 它们是严格字符串匹配，不支持通配或域名解析 - 注意大小写：
HTTP_PROXY和http_proxy在部分工具里行为不同；curl优先看小写，wget只认大写
systemd 服务启动失败，报错 “Connection refused” 但端口明明通
systemd 启动的服务（比如自定义的 myapp.service）默认不继承用户 shell 的环境变量，所以即使你在 ~/.bashrc 里 export 了 http_proxy，服务进程也看不到。但它可能因其他原因“意外”连上代理：比如代码里硬编码了代理地址，或依赖的库（如 Python 的 requests）读了系统级配置文件（/etc/environment 或 /etc/profile.d/*.sh）。
- 查服务实际环境：
systemctl show --property=Environment myapp.service - 临时禁用代理影响：
systemctl set-environment "http_proxy=" "https_proxy=" - 更稳妥的做法是在 service 文件里显式清空：
Environment="http_proxy=" "https_proxy=" "no_proxy="
Python requests 请求卡住或超时，本地 curl 却正常
Python 的 requests 库默认尊重 http_proxy 环境变量，但它还额外读取系统代理配置文件（如 /etc/environment），甚至某些发行版预装的代理管理工具（如 gsettings 在 GNOME 下）也会被 urllib 间接读取。更隐蔽的是，如果设置了 https_proxy 但目标是 HTTP 站点，部分旧版本 requests 仍会尝试走 HTTPS 代理隧道，导致连接 hang 住。
- 验证是否真走代理：
python3 -c "import requests; print(requests.get('http://httpbin.org/ip', timeout=5).text)"，同时用tcpdump -i lo port 8080看有没有流量 - 强制绕过代理：
requests.get(url, proxies={"http": None, "https": None}) - 注意：设
proxies={}不等于绕过，它会 fallback 到环境变量；必须显式设为None
no_proxy 配置无效，内网域名还是走了代理
no_proxy 不是正则，也不是 DNS 模糊匹配。它的规则非常朴素：逗号分隔的字符串列表，每个条目做「后缀匹配」。比如 no_proxy=.example.com,192.168.1.0/24 是错的 —— 它不支持 CIDR，也不支持点开头的通配（.example.com 在多数工具里会被当字面量处理，不会匹配 api.example.com）。
- 正确写法只有两种：
no_proxy="example.com,localhost,127.0.0.1"（完全匹配）或no_proxy="example.com"（匹配所有以example.com结尾的 host，如api.example.com） - 但注意：它不处理端口、协议、路径，只比对 Host 字段；
http://example.com:8080和https://api.example.com都只看example.com或api.example.com - 大小写敏感，且不能有空格：
no_proxy=" example.com "会导致整个变量失效
代理配置真正麻烦的地方不在设，而在“谁在读、什么时候读、按什么规则解释”。同一个变量，在 shell、systemd、Python、Java 里生效逻辑都不同，改完记得验证具体进程的视角，别只信自己的终端。
