Debian 13: Proxy settings break apt/curl — where they hide and how to clean them up

October 9, 2025 • February 3, 2026 • Read: 22 min • Views: 7

Was this helpful?

The symptom is always the same: apt update hangs, curl returns a baffling 407, and the machine swears it has “no proxy configured.”
Then you find out the proxy is configured in five places, half of them invisible to the person currently holding the pager.

Debian 13 doesn’t “break” networking. It just faithfully follows instructions—some of which were left behind by a long-gone bootstrap script, a corporate image,
or that one time someone exported http_proxy in a shell profile and forgot it existed. Let’s hunt the proxy settings down, remove them cleanly,
and prove the system is actually proxy-free.

Fast diagnosis playbook

When apt/curl are failing and you want the fastest path to the truth, don’t start by reading every config file on the planet.
Start by observing behavior and asking: “Is this a proxy decision, a DNS problem, or a TLS/path problem?”

1) Check whether a proxy is being used (environment + apt view)

Run env | grep -i proxy in the same context as the failing command (your shell, root shell, via sudo).
Run apt-config dump | grep -i proxy to see what apt thinks is configured.

If either shows a proxy you didn’t expect, you’ve already found the bottleneck: configuration, not “networking.”

2) Confirm basic routing and DNS without involving proxies

Check DNS: getent ahosts deb.debian.org
Check HTTPS reachability direct: curl -v --noproxy '*' https://deb.debian.org/

If direct works but apt fails, it’s almost always apt config or TLS interception policy differences.

3) Narrow down: which layer is injecting the proxy?

If curl uses a proxy unexpectedly, it’s usually env vars or libcurl config.
If only apt uses a proxy, it’s usually /etc/apt/apt.conf* or an included drop-in.
If services (not interactive shells) use a proxy, suspect systemd manager environment drop-ins.

4) Prove the fix

After changes, re-run apt-config dump, systemctl show-environment, and a test curl -v.
Don’t trust “I removed the line.” Trust outputs.

Facts and context: why proxy ghosts are common

A little history helps explain why proxy settings are so slippery on Linux, and why Debian 13 is not special here—just modern enough to give you more places to hide problems.
Here are some concrete facts that show up in real estates:

Proxy env vars predate today’s tooling. http_proxy and friends became a de facto standard across Unix tools because they were easy to export and script.
Case matters, until it doesn’t. Many tools check lowercase variables first (http_proxy), some check uppercase, and some check both.
apt learned to speak proxies early. The Acquire::Proxy mechanism has been around for years because package managers are a corporate network’s favorite hostage.
HTTPS made proxies political. CONNECT tunneling is fine; TLS interception is where trust stores and policy collide. That’s when “works in browser” diverges from “works in apt.”
systemd normalized “global service environment.” With manager environments and drop-ins, it became easy to make all services inherit a proxy—even when humans don’t see it.
Desktop stacks added their own proxy layers. GNOME settings, network managers, and per-user config can affect some clients while leaving others untouched.
Containers amplified the problem. Build tools and CI often inject proxies at build time, baking them into images or leaving them in /etc/environment.
no_proxy is not standardized. Different clients interpret it differently: leading dots, CIDRs, ports, IPv6 literals—expect surprises.
Authentication failures look like network failures. A proxy returning 407 can show up as “connection refused” depending on the client and logging level.

One paraphrased idea from Gene Kim (reliability/operations author): Improve the system by improving how you see it; fast feedback beats heroic guessing.
That’s the spirit here: don’t guess where the proxy lives. Instrument it.

How apt and curl decide to use a proxy

If you’re troubleshooting, you need a mental model. Not a perfect one—just accurate enough to stop wasting time.

curl: mostly environment-driven, sometimes compiled preferences

curl (via libcurl) will typically look at http_proxy, https_proxy, and no_proxy (plus uppercase variants).
You can override with --proxy or disable with --noproxy or --proxy ''.
The key diagnostic: curl -v tells you whether it’s “Trying proxy …” or “Connected to … directly.”

apt: configuration files first, then environment only if you set it up

apt has its own configuration system and includes. The common hooks are:

Acquire::http::Proxy, Acquire::https::Proxy
Acquire::http::Proxy-Auto-Detect scripts (rare, but a real footgun)
Drop-ins under /etc/apt/apt.conf.d/

apt does not “magically use the desktop proxy settings.” It uses apt config. But apt is often run through sudo, and sudo might preserve proxy env vars depending on policy.
That’s where you get the fun scenario: your user shell has no proxy variables, but sudo apt update does.

Joke #1: A proxy is like a middle manager: sometimes helpful, often unavoidable, and when it’s misconfigured you’ll hear about it immediately.

Where proxy settings hide on Debian 13

There are only so many hiding spots. The trick is to check them in the right order and in the right execution context (interactive shell vs sudo vs system service).

1) Environment variables (interactive and non-interactive)

User shell: ~/.bashrc, ~/.profile, ~/.bash_profile, ~/.zshrc, etc.
System-wide: /etc/environment, /etc/profile, /etc/profile.d/*.sh
sudo: /etc/sudoers and /etc/sudoers.d/* may keep proxy env vars (env_keep).

2) apt configuration and drop-ins

/etc/apt/apt.conf
/etc/apt/apt.conf.d/* (this is the usual culprit)
Sometimes even within repository definitions if automation generates weird Acquire stanzas.

3) systemd manager environment and unit drop-ins

If the failure happens in services (apt timers, unattended-upgrades, custom updaters), check:

systemctl show-environment (manager environment)
Drop-ins under /etc/systemd/system/*.d/ and /etc/systemd/system.conf.d/
Unit files with Environment= lines

4) Tool-specific config (wget, git, docker, etc.)

It’s not always apt/curl. Sometimes apt downloads fine, but a postinst script uses git and fails. Or curl is fine, but wget isn’t.
Debian systems accumulate proxy settings across tools:

~/.wgetrc, /etc/wgetrc
~/.curlrc (less common, but exists)
~/.gitconfig, /etc/gitconfig (http.proxy)

5) Corporate TLS interception: the proxy you can’t remove

Sometimes the proxy isn’t “configured” so much as “enforced.” You can remove the proxy settings and still fail because outbound 443 is transparently intercepted,
which means the machine must trust a corporate CA to validate the MITM certificate. That’s a different problem: trust store, not proxy configuration.
But the symptom is similar: apt and curl fail TLS while browsers appear fine because the browser trusts the enterprise CA via policy.

Practical tasks: commands, outputs, and decisions

Below are field-tested tasks you can run on a Debian 13 host. Each one includes: command, realistic output, what it means, and what decision you make next.
Run them in the same execution context where the issue occurs.

Task 1: See whether your current shell exports proxy variables

cr0x@server:~$ env | grep -i proxy
http_proxy=http://proxy.corp:3128
https_proxy=http://proxy.corp:3128
no_proxy=localhost,127.0.0.1,.corp

Meaning: Your current process environment is telling clients to use a proxy. If you thought “there’s no proxy,” that was wishful thinking.

Decision: Find where these vars are set (user profile, /etc/environment, systemd, CI wrapper). Don’t edit random files yet—identify the source.

Task 2: Check what sudo does to proxy variables

cr0x@server:~$ sudo env | grep -i proxy
http_proxy=http://proxy.corp:3128
https_proxy=http://proxy.corp:3128
no_proxy=localhost,127.0.0.1,.corp

Meaning: sudo is preserving proxy variables into the root environment. This is common in corporate images via Defaults env_keep.

Decision: If you need apt to run without proxy, you must either remove the vars at the source or adjust sudoers. As a temporary test, use sudo -H env -u root -i carefully, or explicitly unset variables for a single command.

Task 3: Test curl’s proxy behavior explicitly

cr0x@server:~$ curl -v https://deb.debian.org/ -o /dev/null
* Uses proxy env variable https_proxy == 'http://proxy.corp:3128'
*   Trying 10.20.30.40:3128...
* Connected to proxy.corp (10.20.30.40) port 3128
> CONNECT deb.debian.org:443 HTTP/1.1
< HTTP/1.1 407 Proxy Authentication Required
curl: (56) CONNECT tunnel failed, response 407

Meaning: curl is obeying https_proxy, reaching the proxy, and being rejected due to missing auth or wrong policy.

Decision: Either configure proxy credentials properly (not my favorite) or remove the proxy config. If the host should not use a proxy, focus on cleanup. If it must, fix authentication and no_proxy.

Task 4: Prove direct connectivity by bypassing proxy variables

cr0x@server:~$ curl -v --noproxy '*' https://deb.debian.org/ -o /dev/null
* Host deb.debian.org:443 was resolved.
*   Trying 151.101.2.132:443...
* Connected to deb.debian.org (151.101.2.132) port 443
* SSL connection using TLSv1.3
> GET / HTTP/1.1
< HTTP/1.1 200 OK

Meaning: Network, DNS, and TLS to the Debian mirror are fine when bypassing proxy logic.

Decision: Stop debugging firewalls. This is a proxy configuration issue, not a connectivity issue.

Task 5: Ask apt what it thinks about proxies

cr0x@server:~$ apt-config dump | grep -iE 'Acquire::(http|https).*Proxy'
Acquire::http::Proxy "http://proxy.corp:3128/";
Acquire::https::Proxy "http://proxy.corp:3128/";

Meaning: apt is configured to use a proxy regardless of shell environment. Even if you unset env vars, apt will still proxy.

Decision: Find the apt config file providing these directives and remove/override it.

Task 6: Locate the apt drop-in that defines the proxy

cr0x@server:~$ sudo grep -RIn --color=never 'Acquire::.*Proxy' /etc/apt/apt.conf /etc/apt/apt.conf.d
/etc/apt/apt.conf.d/02proxy:1:Acquire::http::Proxy "http://proxy.corp:3128/";
/etc/apt/apt.conf.d/02proxy:2:Acquire::https::Proxy "http://proxy.corp:3128/";

Meaning: You have an explicit apt proxy file.

Decision: Decide whether to delete the file (if this host should never proxy) or manage it via configuration management with clear ownership.

Task 7: Check /etc/environment for persistent proxy injection

cr0x@server:~$ sudo sed -n '1,200p' /etc/environment
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
http_proxy="http://proxy.corp:3128"
https_proxy="http://proxy.corp:3128"
no_proxy="localhost,127.0.0.1,.corp"

Meaning: Every login session is going to inherit proxy settings, depending on PAM and service context.

Decision: Remove these lines if the machine shouldn’t proxy. If only some services should, don’t use /etc/environment—it’s a sledgehammer.

Task 8: See what systemd manager environment contains

cr0x@server:~$ systemctl show-environment | grep -i proxy
http_proxy=http://proxy.corp:3128
https_proxy=http://proxy.corp:3128
no_proxy=localhost,127.0.0.1,.corp

Meaning: systemd is holding proxy variables at the manager level. Services started by systemd may inherit them even if interactive shells don’t.

Decision: Identify where they were set (systemctl set-environment, a drop-in, or a distro image script). Plan to unset and restart affected services.

Task 9: Search for systemd drop-ins that inject proxy settings

cr0x@server:~$ sudo grep -RIn --color=never -E 'http_proxy|https_proxy|no_proxy' /etc/systemd
/etc/systemd/system.conf.d/proxy.conf:2:DefaultEnvironment="http_proxy=http://proxy.corp:3128" "https_proxy=http://proxy.corp:3128" "no_proxy=localhost,127.0.0.1,.corp"

Meaning: The proxy is set globally for systemd-managed services via DefaultEnvironment.

Decision: Remove that drop-in if it’s wrong, or scope it to only the units that need it. Global defaults are a debt factory.

Task 10: Check sudoers for env_keep that preserves proxies

cr0x@server:~$ sudo grep -RIn --color=never 'env_keep.*proxy' /etc/sudoers /etc/sudoers.d
/etc/sudoers.d/proxy:1:Defaults env_keep += "http_proxy https_proxy no_proxy"

Meaning: Even if you clear variables in your profile, someone may have deliberately preserved them through sudo.

Decision: If the host must be proxy-free, remove this and validate that automation (Ansible, cloud-init) isn’t re-adding it.

Task 11: Inspect apt’s actual failure with debug output

cr0x@server:~$ sudo apt -o Debug::Acquire::https=true update
Ign:1 https://deb.debian.org/debian trixie InRelease
Connecting to proxy.corp (10.20.30.40)
Answer for: https://deb.debian.org/debian/dists/trixie/InRelease
HTTP/1.1 407 Proxy Authentication Required
Err:1 https://deb.debian.org/debian trixie InRelease
  407  Proxy Authentication Required [IP: 10.20.30.40 3128]
Reading package lists... Done

Meaning: apt is definitely using a proxy, and the proxy rejects it. Debug output removes doubt.

Decision: Fix proxy auth (if needed) or remove proxy config. Don’t waste time on mirror selection or IPv6 toggles.

Task 12: Neutralize apt proxy for a single run (safe diagnostic)

cr0x@server:~$ sudo apt -o Acquire::http::Proxy="" -o Acquire::https::Proxy="" update
Hit:1 https://deb.debian.org/debian trixie InRelease
Hit:2 https://security.debian.org/debian-security trixie-security InRelease
Reading package lists... Done

Meaning: With proxies disabled, apt succeeds. That’s your smoking gun.

Decision: Proceed with permanent cleanup: remove proxy directives and environment variables, then verify.

Task 13: Confirm no stray wget proxy config

cr0x@server:~$ grep -nE 'use_proxy|http_proxy|https_proxy' ~/.wgetrc /etc/wgetrc 2>/dev/null
/etc/wgetrc:16:use_proxy = on
/etc/wgetrc:18:http_proxy = http://proxy.corp:3128/

Meaning: wget will use a proxy even if you cleaned apt and curl env vars. Tool-specific configs matter.

Decision: Either remove/disable proxy in wget config or accept that wget remains proxied (but then be consistent and document it).

Task 14: Validate trust store when a proxy intercepts TLS

cr0x@server:~$ openssl s_client -connect deb.debian.org:443 -servername deb.debian.org -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Peer certificate: CN = deb.debian.org
Verification: OK

Meaning: Direct TLS verifies fine. If the same command through a proxy gives verification failures, you’re dealing with TLS interception trust.

Decision: Don’t “fix” this by disabling verification. Install the correct enterprise CA (if policy requires interception) or bypass the intercepting proxy.

Task 15: Catch no_proxy mismatches that force internal traffic through proxy

cr0x@server:~$ env | grep -i no_proxy
no_proxy=localhost,127.0.0.1,.corp,10.0.0.0/8

Meaning: Someone tried to use CIDR in no_proxy. Many tools don’t interpret CIDRs here; they want host suffixes or literal IPs.

Decision: Replace CIDR with explicit domains and key IPs that matter, and test per tool. Assume inconsistency until proven otherwise.

Task 16: Confirm what unattended-upgrades sees (service context)

cr0x@server:~$ systemctl cat unattended-upgrades.service
# /lib/systemd/system/unattended-upgrades.service
[Service]
Type=oneshot
ExecStart=/usr/bin/unattended-upgrade

cr0x@server:~$ systemctl show -p Environment unattended-upgrades.service
Environment=http_proxy=http://proxy.corp:3128 https_proxy=http://proxy.corp:3128 no_proxy=localhost,127.0.0.1,.corp

Meaning: The service itself has proxy environment set (maybe via a drop-in).

Decision: Remove the unit-level environment, or add an override that clears it if you want unattended upgrades to go direct.

Cleanup strategy: remove, neutralize, and lock it down

Cleaning proxy settings is easy to do badly. “I deleted the line” is how you get a week of intermittent failures because the proxy pops back via a different layer.
The right approach is boring: identify sources, remove or scope them, then prove the runtime environment is clean.

Step 1: Decide the policy for this host

Start with a blunt question: Should this machine ever use an HTTP(S) proxy?

No: remove proxy settings everywhere; also remove sudo env_keep; ensure systemd default environment doesn’t contain proxy.
Yes, globally: centralize it in one place (apt drop-in + systemd DefaultEnvironment) and document it; ensure auth and CA trust are correct.
Only for specific services: never set /etc/environment or global systemd defaults; use unit-specific drop-ins.

Step 2: Clean apt the right way

apt is deterministic. That’s good news. Put proxy config in one explicit file if you must have it, and delete everything else.

Preferred: a single file like /etc/apt/apt.conf.d/02proxy (owned by config management).
Avoid: sprinkling Acquire directives across multiple drop-ins with unclear ordering.

If you are removing proxies, remove that file (or comment it out) and verify with apt-config dump.

Step 3: Clean environment injection

If you want a proxy-free system, /etc/environment is not your friend. It’s a global lever and tends to outlive the reason it was created.
Remove proxy lines there and in profile scripts.

Then address sudo. If env_keep preserves proxy variables, you’ll keep reintroducing them into root commands.

Step 4: Clean systemd’s global environment

If systemctl show-environment contains proxy variables, fix the root cause:

Remove DefaultEnvironment entries from systemd drop-ins if they aren’t intended.
Unset manager environment variables and restart relevant services (or reboot if you want the blunt guarantee).

Systemd is extremely good at doing exactly what it was told. That includes obeying mistakes forever.

Step 5: Verify with tests that match your failure mode

Verification should include:

env | grep -i proxy (user shell)
sudo env | grep -i proxy (root via sudo)
systemctl show-environment | grep -i proxy (service manager)
apt-config dump | grep -i proxy (apt view)
curl -v (behavior)

Joke #2: The only thing more persistent than a misconfigured proxy is the ticket requesting “just a quick change” right before a holiday.

Three corporate mini-stories from real life

Mini-story 1: The incident caused by a wrong assumption

A team migrated a fleet of Debian servers from an older environment into a new network segment. The old segment required an outbound proxy.
The new segment had direct egress with strict firewall rules and no proxy at all. Everyone agreed: “No proxy needed anymore.”

They removed the proxy from their CI pipeline and stopped passing http_proxy variables into builds. Testing looked fine.
Then, two weeks later, a security update rollout started failing—but only on a subset of hosts. Some updated fine, others stalled, and a few spammed logs with 407 errors.

The wrong assumption: “If it’s not in the CI variables, it’s gone.” On the failing hosts, the proxy lived in /etc/apt/apt.conf.d/ from an old golden image.
Those machines had been created months earlier and never reprovisioned, just patched in place. The proxy hostname still resolved, but the proxy itself now required authentication from a different realm.

The fix was embarrassingly simple: remove the apt proxy drop-in, remove stale /etc/environment entries, and stop preserving proxies through sudo.
The lesson was the real win: inventory where configuration can come from. Assumptions don’t scale, and Debian is happy to keep old instructions forever.

Mini-story 2: The “optimization” that backfired

Another org wanted faster updates. They set up an internal caching proxy and pointed all apt traffic at it.
It looked like a clean optimization: less bandwidth, faster installs, fewer timeouts across WAN links.

The first month was great. Then a proxy maintenance window happened. The proxy came back up with a new TLS interception policy and a rotated enterprise CA.
Browsers updated trust automatically via device management. Servers did not.

Suddenly apt started failing with certificate verification errors. Someone “fixed” it by setting apt to ignore TLS verification for a short window.
That “short window” lasted longer than it should have, because the failures stopped and people moved on. The proxy remained a single point of failure, plus a silent trust-anchor dependency.

When an audit asked how package integrity was assured, the answer was a lot of throat-clearing and a scramble to re-enable verification and deploy CA updates properly.
The optimization wasn’t wrong. The operational maturity around it was.

The durable fix: eliminate TLS interception for Debian mirror traffic where possible, or manage CA distribution as a first-class dependency.
And for performance, use local mirrors or apt caching layers that don’t require MITM.

Mini-story 3: The boring practice that saved the day

A platform team had a habit that looked tedious: every image baked into production had a “network contract” file checked by CI.
It stated whether the host should use a proxy, and if yes, exactly where it was configured (apt drop-in, systemd unit overrides, and a managed CA bundle).

During a datacenter migration, a batch of Debian 13 VMs suddenly couldn’t install packages in an isolated staging VLAN.
The incident response looked dramatic from the outside—alerts, failed deployments, delayed cutover—but internally it was procedural.

They ran three commands: apt-config dump for proxy directives, systemctl show-environment for inherited variables, and curl -v --noproxy '*' to validate direct egress.
Within minutes they proved the VLAN blocked direct internet, and the staging subnet needed a proxy by design.

Here’s the saving part: their proxy settings were not scattered.
A single apt config drop-in and a single systemd drop-in could be enabled for that environment via config management.
No hand edits, no guessing, no “works on my shell.” The migration completed with a clean paper trail.

Common mistakes: symptom → root cause → fix

These are the patterns I see most often on Debian estates. The best part is they’re predictable.

1) apt fails with 407, curl fails with 407

Symptom: Proxy Authentication Required in apt and curl.

Root cause: Proxy is configured (env or apt), but credentials are missing/invalid, or proxy policy changed.

Fix: If proxy shouldn’t be used, remove it from apt configs and environment sources. If it should, use an authenticated proxy method appropriate for your org and test with curl -v.

2) curl works, apt fails (or vice versa)

Symptom: One tool works, the other times out or proxies.

Root cause: Different configuration sources: apt uses /etc/apt/apt.conf.d; curl uses env vars or ~/.curlrc.

Fix: Compare apt-config dump and env | grep -i proxy. Fix the layer that matches the failing tool.

3) “I removed the proxy, but services still use it”

Symptom: Interactive tests succeed; unattended-upgrades or a daemon still hits proxy.

Root cause: systemd manager environment or unit drop-ins still define proxy variables.

Fix: Check systemctl show-environment and systemctl show -p Environment <unit>. Remove/override, then restart the service (or reboot for certainty).

4) apt fails with TLS errors only when proxy is involved

Symptom: certificate verify failed, sometimes after a proxy change.

Root cause: TLS interception requires an enterprise CA that isn’t installed in the system trust store.

Fix: Install the enterprise CA into Debian’s trust store using your standard method and verify with openssl s_client. Do not disable verification in apt as a “temporary” fix.

5) no_proxy “does nothing” for internal domains

Symptom: Internal endpoints still go through proxy, causing latency or auth failures.

Root cause: no_proxy format mismatch (CIDR unsupported, leading dot behavior differs, ports ignored).

Fix: Use domain suffixes and explicit hostnames. Validate per client with curl -v and the exact URL used by the failing process.

6) Everything works as user, fails under sudo

Symptom: curl succeeds; sudo curl uses proxy and fails.

Root cause: sudoers preserves proxy env vars (env_keep) or root shell profiles differ.

Fix: Audit /etc/sudoers.d and root’s shell startup files. Prefer not to preserve proxy vars globally unless there’s a policy reason.

Checklists / step-by-step plan

Checklist A: 10-minute proxy triage (interactive)

Run env | grep -i proxy. If present, identify source (user/system profiles).
Run sudo env | grep -i proxy. If different from user, check sudoers env_keep.
Run apt-config dump | grep -i proxy. If present, find the file in /etc/apt/apt.conf.d.
Run curl -v https://deb.debian.org/ -o /dev/null to see whether it uses a proxy.
Run curl -v --noproxy '*' https://deb.debian.org/ -o /dev/null to prove direct path works.
If services fail, run systemctl show-environment | grep -i proxy.

Checklist B: Proxy removal plan (host should be direct)

Delete or comment apt proxy directives in the identified file under /etc/apt/apt.conf.d/.
Remove proxy lines from /etc/environment and any /etc/profile.d scripts that set them.
Remove sudoers rules preserving proxy variables unless explicitly required.
Remove systemd DefaultEnvironment proxy settings (or limit them to specific units instead).
Restart affected services; for broad changes, schedule a reboot.
Re-verify with the five outputs: user env, sudo env, systemd environment, apt-config dump, curl -v behavior.

Checklist C: Proxy must exist, but make it sane

Choose one authoritative configuration mechanism per scope:
- For apt: one managed file in /etc/apt/apt.conf.d/.
- For services: unit drop-ins with Environment= (not global defaults unless truly global).
Define no_proxy carefully: include metadata endpoints, cluster control planes, internal registries, and localhost.
If TLS interception is involved, manage the enterprise CA distribution and verify on hosts (don’t rely on browsers).
Document ownership: who changes proxy host/port/auth, and how changes roll out safely.

FAQ

1) Why does `apt update` use a proxy when my shell shows no `http_proxy`?

Because apt can be configured independently via /etc/apt/apt.conf and /etc/apt/apt.conf.d/*.
Check with apt-config dump | grep -i proxy.

2) Why does `sudo apt update` behave differently from `apt update`?

sudo may preserve proxy variables (env_keep), and root may have different shell startup files or environment.
Compare env | grep -i proxy vs sudo env | grep -i proxy.

3) Where is the “main” place Debian stores proxy settings?

There isn’t one. For apt it’s apt config files; for many CLI tools it’s environment variables; for services it’s systemd environments or unit overrides.
That’s why proxy cleanup is a scavenger hunt unless you standardize.

4) Can I just set `Acquire::https::Proxy "false";`?

You can disable proxies by setting empty strings for the proxy options, or by removing the directives. For a one-shot run, use:
apt -o Acquire::https::Proxy="" -o Acquire::http::Proxy="" update.
For permanent behavior, remove the source file or manage it explicitly.

5) Why does `no_proxy` not work for CIDR ranges?

Because support varies by client, and many do not parse CIDR in no_proxy. Prefer explicit domains and hostnames.
Test with the exact client and URL; don’t assume portability.

6) I removed proxies, but unattended upgrades still fail. Why?

Unattended upgrades run as a service. systemd may still provide proxy environment variables via manager environment or unit drop-ins.
Check systemctl show-environment and systemctl show -p Environment unattended-upgrades.service.

7) apt fails with certificate errors only on corporate networks. Is that a proxy problem?

Often it’s TLS interception. The “proxy” is doing MITM and presenting certificates signed by an enterprise CA not in Debian’s trust store.
Fix by installing the enterprise CA properly, or by bypassing interception for Debian mirrors if policy allows.

8) What’s the safest way to prove the proxy is the issue without changing config?

For curl: run curl -v --noproxy '*' and compare behavior.
For apt: run apt -o Acquire::http::Proxy="" -o Acquire::https::Proxy="" update.
If that works, you’ve isolated the culprit.

9) Should I store proxy credentials in apt config files?

Avoid it if you can. Credentials end up readable to more places than you expect (backups, logs, support bundles).
If the organization requires authenticated proxies, use the approved secret distribution mechanism and minimize where secrets live.

10) How do I stop proxy settings from coming back?

Find the writer: cloud-init, config management, image bake scripts, or compliance tooling. Remove the source of truth there.
If you only “fix the server,” the next run will reintroduce it.

Conclusion: practical next steps

Proxy issues feel like networking problems because the failure mode is “can’t reach the internet.” They’re usually configuration problems because the system is obeying hidden instructions.
Debian 13 gives you a clean set of levers—apt config, environment, systemd—but it also gives you enough rope to make a mess.

Next steps that actually work in production:

Run the fast diagnosis commands and decide whether the host should be proxied at all.
Make proxy configuration single-source and scoped: one apt drop-in, unit-specific systemd env, no global /etc/environment unless truly required.
Remove sudo env_keep for proxies on hosts that should be direct.
Prove the fix with outputs, not vibes: apt-config dump, systemctl show-environment, and curl -v without and with proxy bypass.