When ping works but curl fails — a NAS networking ghost (and a stupid fix)

Very normal maintenance day. Very abnormal network behavior.
Also: yes, it was my fault.

Yappings

Yes as you all know, I am currently running an arch Linux on a very-aged laptop which holds several services:

Docker services (Jellyfin / Paperless-NGX / bots)
Samba
Several future features I may totally forgot days after but that doesn’t matter

Unfortunately, due to great pressure of UWaterloo, I lost my passionate writing my personal blog until a new job cycle begins several days after. Therefore, I have to make up my mind to write something for… mostly my potential future HRs idk.

Onegai, please let me find a job.

ping 8.8.8.8 ✅
curl https://www.google.com ❌ timeout
curl -v ... showed it was using all_proxy=socks://127.0.0.1:8889
proxy not running → HTTP/HTTPS silently routed into the void
fix: unset all_proxy http_proxy https_proxy + remove from shell init

Background

My NAS hosts a few personal services and runs most things in Docker.
It’s stable enough that I assume the network is fine… until I touch something and reality disagrees.

Symptom: “Ping is fine, but the web is dead”

What worked

ping 8.8.8.8 worked normally
routes looked sane (ip route)
nothing obvious was blocked

What failed

curl https://www.google.com timed out
API calls from Docker containers failed too
anything relying on external HTTPS became unusable

This is the key mismatch:

ICMP is OK, but HTTP/HTTPS is not.

Wait, what is ICMP?

ICMP stands for Internet Control Message Protocol.

If you don’t remember it clearly — that’s normal.
Most people only meet ICMP through one command:

ping

ICMP is not used to “send data” like HTTP or HTTPS.
It’s mainly for network diagnostics and control messages:

“Are you alive?”
“Can you hear me?”
“This route is unreachable.”
“Your packet is too big, try smaller ones.”

That’s why this bug was so misleading:

ping uses ICMP
curl uses HTTP/HTTPS (TCP)

They go through very different code paths.

So:

ICMP can work perfectly
while TCP-based applications silently fail

This is also why:

proxies
environment variables
application-level configs

can break curl without touching ping at all.

If ping works but apps don’t,
the problem is almost never “the cable”.

My first checks (boring, but they rule out the obvious)

1) Routing

Checked default route and whether traffic was being forced through Tailscale / VPN policy routes:

ip route
ip rule

2) DNS

Confirmed domains resolve (because “curl fails” sometimes is just DNS being cursed):

cat /etc/resolv.conf
dig google.com (or nslookup google.com)

3) Tailscale interference

Temporarily ruled out overlay routing weirdness:

stop/disable Tailscale temporarily (whatever your setup is)

None of these explained why ping was happy but curl was not.

The clue that mattered: `curl -v`

I ran curl in verbose mode:

curl -v https://www.google.com

And saw something like:

1	Uses proxy env variable all_proxy == 'socks://127.0.0.1:8889'

That instantly changed the question from:

“Why is my network broken?”

to:

“Why is curl not using my network at all?”

Root cause: a stale proxy environment variable

Some time ago, I had set:

all_proxy=socks://127.0.0.1:8889

…but the local SOCKS proxy service was no longer running.

So the behavior made perfect sense:

ping uses ICMP → doesn’t care about HTTP proxy → ✅
curl respects proxy env vars → routes to 127.0.0.1:8889 → ❌ (nothing is listening)
Docker containers and HTTP clients that inherit env vars → same failure mode

This is why “ping works” didn’t mean “the internet works”.

Fix

Immediate fix (current shell)

Run:

unset all_proxy http_proxy https_proxy

(If you only set one of them, unset just that one.)

Permanent fix (don’t let it come back)

Search your shell config files (~/.bashrc, ~/.zshrc, etc.) and remove any proxy exports, e.g.:

export all_proxy=...
export http_proxy=...
export https_proxy=...

Restart shell / re-login, then re-test with:

curl https://www.google.com

Key takeaways (for future me)

Ping working ≠ application connectivity working
Always check curl -v early if HTTP behaves weirdly
Proxy env vars can silently affect everything
Old configs are basically landmines with a timer

What’s next

I’ll probably write a quick “NAS networking checklist” post later:
- DNS / routes / MTU / proxy env vars / Docker networking
Also: maybe a supplement of former projects I ever done before (eg. DockerHub & How to Dockerlize a software)