Hey! Had the same issue last week. Make sure you're editing the right file—sometimes people mix up `/etc/wgetrc` and `~/.wgetrc`.
Also, try adding `use_proxy=on` right above your proxy lines. Wget can be picky about that.
If it still doesn’t work, check if your proxy needs auth with `proxy_user` and `proxy_passwd`.
For wget proxy /etc/wgetrc, you might wanna try setting env vars too. Run:
```
export http_proxy=http://proxy.example.com:8080
export https_proxy=http://proxy.example.com:8080
```
Then test wget. If it works, you know the issue is with the file, not the proxy itself.
Dude, uncomment the `#https_proxy` and `#http_proxy` lines in `/etc/wgetrc` first! Wget ignores commented stuff, obviously.
Also, if you’re on a system with `systemd`, check if some global config is overriding your settings.
Pro tip: Use `wget --debug` to see if it’s even reading `/etc/wgetrc`. Might help pinpoint where it’s failing.
And yeah, like others said, `use_proxy=on` is clutch. Forgot that once and wasted an hour debugging.
OP reply:
Whoa, thanks for all the tips! Didn’t realize `use_proxy=on` was missing—that fixed it.
Quick Q: Is there a way to test if wget is using the proxy without hitting a live site? Like a dry-run flag?
Also, good call on the env vars—totally forgot about those. Gonna clean up my `/etc/wgetrc` now. Cheers!
If you’re behind a corp proxy, they might block non-authenticated requests. Try adding:
```
proxy_user = your_username
proxy_passwd = your_password
```
But be careful—don’t leave passwords in plaintext! Maybe use `~/.wgetrc` with tighter permissions instead.
Check if SELinux or AppArmor is blocking wget from reading `/etc/wgetrc`. Run `audit2allow` on Linux if you see denials in logs.
Also, `strace wget URL` might show if it’s even trying to use the proxy.
For wget proxy /etc/wgetrc, sometimes the file needs strict permissions. Try `chmod 644 /etc/wgetrc` if it’s too restrictive.
And yeah, uncommenting lines is a must. Wget won’t magically read commented configs.