Debian 13 “Broken pipe” errors: when it’s harmless and when it’s your first warning (case #75)

What “broken pipe” really means on Debian 13

On Debian 13, like every other modern Linux, “broken pipe” is usually your application surfacing a classic UNIX condition:
EPIPE (errno 32). In plain terms: your process attempted a write() (or equivalent send)
to a pipe or socket that no longer has a reader on the other end.

Where the message comes from

• Applications print “Broken pipe” when they catch EPIPE and log it (Go, Java, Python, Ruby, Nginx, Apache, PostgreSQL clients, you name it).
• Shell pipelines sometimes print it when a downstream consumer exits early (think head), and upstream keeps writing.
• Libraries can convert EPIPE into an exception (e.g., java.io.IOException: Broken pipe, BrokenPipeError: [Errno 32] in Python).
• Signals: by default, writing to a closed pipe can trigger SIGPIPE which terminates the process unless handled/ignored. Many network servers ignore SIGPIPE specifically to avoid dying and instead log EPIPE.

The key operational detail: EPIPE is the writer discovering that the peer is gone. It does not prove the writer is buggy,
and it does not prove the network is bad. It proves a lifecycle mismatch: one side still writing, the other side done.

Broken pipe vs. connection reset: why the distinction matters

Engineers often lump “broken pipe” together with “connection reset by peer”. They’re related but not identical.
“Connection reset” is typically ECONNRESET: the peer (or middlebox) sent a TCP RST, tearing down the connection abruptly.
“Broken pipe” is usually EPIPE when you write after the peer has closed (FIN) and you’ve processed it.

That nuance matters because a FIN-after-response is normal for many clients, while a rash of RSTs can mean a proxy timeout, kernel pressure,
or a service process being shot in the head. Debian 13 didn’t change TCP, but newer defaults and newer versions of daemons can change
how often you see these messages.

One quote I keep taped to the mental dashboard: Werner Vogels (Amazon CTO) popularized the reliability mindset—
“Everything fails, all the time” (paraphrased idea). “Broken pipe” is often your first little postcard from that reality.

Harmless noise vs. first warning

When “broken pipe” is usually harmless

You can safely downgrade the urgency when all of these are true:

• It correlates with client aborts: users navigating away, mobile clients flipping networks, browser tabs closed.
• Errors are low rate: a small percentage of requests, stable over time, no upward trend during load.
• It happens after response headers/body were mostly sent: classic “client closed connection while sending response”.
• It’s on endpoints with long downloads: large files, streaming responses, SSE/websocket-ish behavior without proper keepalive.
• Metrics show no damage: p95/p99 latencies, 5xx rate, saturation, and queue depths are boring.

Example: Nginx logs broken pipe because the browser stopped reading a large response. Your server did nothing wrong;
your log level is just honest.

When “broken pipe” is your first warning

Treat it as a pager smell when any of these are true:

• Rate spikes during deploys: suggests connection churn, slow starts, readiness issues, or old pods draining badly.
• It coincides with timeouts: upstream timeouts, proxy timeouts, load balancer idle timeouts.
• It appears with memory/CPU pressure: the server stalls, clients give up, then writes hit dead sockets.
• It clusters on specific peers: one AZ, one NAT gateway, one proxy tier, one storage-backed endpoint.
• It shows up in internal RPC: service-to-service calls breaking is rarely “user behavior”.
• It correlates with TCP retransmits/resets: suggests packet loss, MTU issues, conntrack pressure, or a bad middlebox day.

Joke #1: “Broken pipe” is the log equivalent of your coworker saying “we should talk”—it might be nothing, but you’re not sleeping until you know.

The operational rule

If “broken pipe” is mostly edge traffic and your service health is green, it’s noise you can tame.
If it’s east-west traffic, increasing, or paired with timeouts/5xx, it’s a symptom. Chase the underlying reason, not the string.

Facts and history you can use in a postmortem

1. “Broken pipe” comes from UNIX pipes: writing to a pipe with no reader historically raised SIGPIPE; the phrase predates modern TCP services.
2. EPIPE is errno 32 on Linux: that’s why you see “Errno 32” in Python and friends.
3. SIGPIPE default action is process termination: many servers explicitly ignore SIGPIPE to survive client disconnects.
4. TCP has two common teardown modes: a graceful close (FIN) vs. an abrupt reset (RST). Different failure signatures, different blame.
5. HTTP/1.1 keep-alive made this more visible: persistent connections increased the surface area for idle timeouts and half-closed states.
6. Reverse proxies log “broken pipe” a lot: they sit between clients and upstreams and are the first to notice when one side bails.
7. Middleboxes love timeouts: load balancers, NAT gateways, firewalls, and proxies often enforce idle timers that applications forget to match.
8. Linux can report socket errors late: a write may succeed locally and only later report failure; that’s why the timing feels “random”.
9. “Client aborted” is not always a user: health checks, synthetic monitoring, scanners, and aggressive SDKs also open-and-drop connections.

Fast diagnosis playbook

This is the order that finds real bottlenecks fast. It’s optimized for on-call reality: you need a direction in 10 minutes, not a thesis in 10 hours.

First: classify where it happens (edge vs. internal)

• Edge / public HTTP: start with proxy logs (Nginx/Apache/Envoy), client abort patterns, and timeouts.
• Internal RPC / database: treat as a reliability incident until proven otherwise.
• Shell scripts / cron: often harmless pipeline behavior, but can hide real partial output problems.

Second: correlate with timeouts and saturation

• Check 499/408/504 (or equivalent) and upstream timeout counters.
• Check CPU steal, runnable queue, memory pressure, IO wait, disk latency.
• Check network retransmits/resets.

Third: confirm who closed first

• Packet capture for a minute on the affected node (yes, even in 2025, tcpdump still pays rent).
• Inspect keepalive settings across client, proxy, load balancer, and server.
• Look for deploy/drain behavior: readiness gates, connection draining, graceful shutdown.

Fourth: decide the fix class

• Noise: tune logging, reduce stack traces, add sampling, and improve client abort visibility.
• Timeout mismatch: align idle timeouts and keepalives; tune proxy buffering.
• Overload: add capacity, reduce work per request, fix slow IO (storage or network), add backpressure.
• Crashes: fix OOM, segfault, restart storms, and bad deploy practices.

Practical tasks: commands, outputs, decisions (12+)

These are the tasks I actually run on Debian hosts. Each has three parts: the command, what the output means, and what decision you make next.
Commands assume root or sudo when necessary.

Task 1: Find the exact error wording and which service emits it

cr0x@server:~$ sudo journalctl -S -2h -p warning..alert | grep -i -E "broken pipe|EPIPE|SIGPIPE" | tail -n 20
Dec 31 09:12:41 api-01 nginx[1234]: *918 writev() failed (32: Broken pipe) while sending to client, client: 203.0.113.10, server: _, request: "GET /download.bin HTTP/1.1"
Dec 31 09:13:02 api-01 app[8871]: ERROR send failed: Broken pipe (os error 32)

Meaning: You now know whether it’s Nginx, the app, a sidecar, or something else.
Nginx “while sending to client” screams client abort; app-level send failures can be downstream (DB, cache, internal RPC).
Decision: Split the investigation path: edge traffic patterns for Nginx; dependency tracing for app errors.

Task 2: Check if deploys or restarts line up with the spike

cr0x@server:~$ sudo journalctl -S -6h -u nginx -u app.service --no-pager | grep -E "Started|Stopping|Reloaded|SIGTERM|exited" | tail -n 30
Dec 31 08:59:58 api-01 systemd[1]: Reloaded nginx.service - A high performance web server and a reverse proxy server.
Dec 31 09:00:01 api-01 systemd[1]: Stopping app.service - API Service...
Dec 31 09:00:03 api-01 systemd[1]: app.service: Main process exited, code=killed, status=15/TERM
Dec 31 09:00:03 api-01 systemd[1]: Started app.service - API Service.

Meaning: Connection churn during reload/restart can produce EPIPE as in-flight clients lose their upstream.
Decision: If errors cluster around restarts, inspect graceful shutdown, connection draining, readiness, and proxy retries.

Task 3: Look for client-abort status codes at the proxy

cr0x@server:~$ sudo awk '$9 ~ /^(499|408|504)$/ {c[$9]++} END{for (k in c) print k, c[k]}' /var/log/nginx/access.log
499 317
504 12
408 41

Meaning: Many 499s usually mean the client closed early (Nginx convention). 504 suggests upstream timeout.
408 indicates request timeout (client too slow or header read timing out).
Decision: If 499 dominates with stable 5xx, it’s likely harmless noise; if 504 rises with EPIPE, chase latency/overload upstream.

Task 4: Identify which endpoint is generating the broken pipes

cr0x@server:~$ sudo awk '$9==499 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head
  211 /download.bin
   63 /reports/export
   31 /api/v1/stream
   12 /favicon.ico

Meaning: Long-running downloads and exports are classic client-abort magnets.
Decision: If it’s concentrated on big responses, consider buffering, range support, resumable downloads, and log sampling for 499/EPIPE.

Task 5: Check upstream response time patterns (is the server slow?)

cr0x@server:~$ sudo awk '{print $(NF-1)}' /var/log/nginx/access.log | awk -F= '{print $2}' | sort -n | tail -n 5
12.991
13.105
13.442
14.003
15.877

Meaning: This assumes you log something like upstream_response_time=....
High tail latencies mean clients may time out or give up, causing EPIPE when you finally write.
Decision: If tails are high, pivot to CPU, memory, and IO checks; also verify proxy timeouts aren’t too aggressive.

Task 6: Confirm system pressure (CPU, load, memory) around the event

cr0x@server:~$ uptime
 09:14:22 up 23 days,  4:11,  2 users,  load average: 18.91, 19.22, 17.80

Meaning: Load average far above CPU count (or above what’s normal for this host) suggests contention.
Decision: If load is high, validate whether it’s CPU saturation, IO wait, or runnable queue backlog.

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi        29Gi       420Mi       1.2Gi       1.6Gi       1.0Gi
Swap:          2.0Gi       1.8Gi       200Mi

Meaning: Low available memory plus heavy swap is how you get “everything is slow, clients bail, writes EPIPE”.
Decision: If swapping, treat broken pipe as a symptom. Stop memory bleed, add memory, lower concurrency, or fix caching strategy.

Task 7: Check for OOM kills (the silent broken-pipe factory)

cr0x@server:~$ sudo journalctl -k -S -6h | grep -i -E "oom|killed process|out of memory" | tail -n 20
Dec 31 09:00:02 api-01 kernel: Out of memory: Killed process 8871 (app) total-vm:4123456kB, anon-rss:1987654kB, file-rss:0kB, shmem-rss:0kB

Meaning: If the kernel is killing your app, clients will see disconnects; upstreams will see broken pipe when trying to write back.
Decision: Stop treating EPIPE as a logging annoyance; fix memory limits, leaks, or request fan-out causing spikes.

Task 8: Inspect TCP resets and retransmits (network truth serum)

cr0x@server:~$ sudo nstat -az | egrep "TcpExtTCPSynRetrans|TcpRetransSegs|TcpOutRsts|TcpInRsts"
TcpExtTCPSynRetrans             18                 0.0
TcpRetransSegs                  4201               0.0
TcpOutRsts                      991                0.0
TcpInRsts                       874                0.0

Meaning: Retransmits and RSTs trending up can indicate packet loss, overload, conntrack issues, or idle-timeout enforcement.
Decision: If RSTs/retransmits spike with EPIPE, capture traffic and review middlebox timeouts; also check NIC errors.

Task 9: Check NIC and kernel-level drops/errors

cr0x@server:~$ ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    RX:  bytes packets errors dropped  missed   mcast
    9876543210 1234567      0   12451       0   12345
    TX:  bytes packets errors dropped carrier collsns
    8765432109 2345678      0    9421       0       0

Meaning: Drops at the interface level are not always fatal, but they correlate strongly with retransmits and “random” disconnects.
Decision: If drops are rising, check qdisc/backlog tuning, interrupt moderation, host CPU saturation, or upstream network congestion.

Task 10: See which connections are in which state (are you drowning in half-closed sockets?)

cr0x@server:~$ ss -s
Total: 2134
TCP:   1821 (estab 712, closed 943, orphaned 7, timewait 122, ports 0)
Transport Total     IP        IPv6
RAW       0         0         0
UDP       31        27        4
TCP       878       831       47
INET      909       858       51
FRAG      0         0         0

Meaning: Lots of timewait can be normal for short-lived connections, but large swings can mean keepalive or reuse issues.
Decision: If estab is huge and stable, you may have slow clients; if closed/orphaned spikes, investigate abrupt terminations and crashes.

cr0x@server:~$ ss -tan state time-wait '( sport = :443 )' | head
State      Recv-Q Send-Q Local Address:Port Peer Address:Port
TIME-WAIT  0      0      10.0.1.10:443     198.51.100.25:51322
TIME-WAIT  0      0      10.0.1.10:443     203.0.113.77:44118

Meaning: Confirms the port and state distribution.
Decision: If TIME-WAIT is excessive and causing port exhaustion on clients or NAT, increase reuse via design (keepalive) rather than kernel hacks.

Task 11: Verify timeout mismatches (Nginx example)

cr0x@server:~$ sudo nginx -T 2>/dev/null | egrep "keepalive_timeout|proxy_read_timeout|proxy_send_timeout|send_timeout" | head -n 20
keepalive_timeout 65;
send_timeout 30s;
proxy_read_timeout 60s;
proxy_send_timeout 60s;

Meaning: If send_timeout is lower than your typical response time for big downloads, you’ll see broken pipes.
If proxy_read_timeout is too low, upstream requests will be cut, and the proxy may reset.
Decision: Align timeouts across the chain (client ↔ LB ↔ proxy ↔ app). Raise timeouts only when you can afford the resource pinning.

Task 12: Inspect systemd service limits and kill behavior

cr0x@server:~$ sudo systemctl show app.service -p TimeoutStopUSec -p KillSignal -p KillMode -p Restart -p RestartSec
TimeoutStopUSec=30s
KillSignal=SIGTERM
KillMode=control-group
Restart=on-failure
RestartSec=2s

Meaning: If your app needs 90 seconds to drain, but systemd gives it 30, you’ll generate disconnects during deploys.
Decision: Tune graceful shutdown: increase TimeoutStopUSec, implement drain endpoints, and ensure the proxy stops sending traffic first.

Task 13: Confirm who closed first with a short tcpdump

cr0x@server:~$ sudo tcpdump -i eth0 -nn -s 0 -c 50 'tcp port 443 and (tcp[tcpflags] & (tcp-fin|tcp-rst) != 0)'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
09:13:02.112233 IP 203.0.113.10.51544 > 10.0.1.10.443: Flags [F.], seq 12345, ack 67890, win 64240, length 0
09:13:02.112450 IP 10.0.1.10.443 > 203.0.113.10.51544: Flags [R], seq 67890, win 0, length 0

Meaning: You’re seeing FIN from client and then a reset from server (or vice versa). This is the ground truth of who hung up.
Decision: If clients send FINs early, it’s likely aborts/timeouts on their side; if server sends RSTs, look for proxy/app closes, crashes, or aggressive timeouts.

Task 14: If storage is involved, check IO latency (slow disk makes clients bail)

cr0x@server:~$ iostat -xz 1 3
Linux 6.12.0 (api-01)  12/31/2025  _x86_64_  (8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          22.10    0.00    5.20   18.30    0.00   54.40

Device            r/s     w/s   rkB/s   wkB/s  avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
nvme0n1         90.0   120.0  8200.0  5400.0     92.0     7.80   38.20   41.10   35.90   0.80  17.00

Meaning: High await and %iowait can stall request handling. Clients time out, then you write: EPIPE.
Decision: If disk latency rises with broken pipes, fix the IO path: query optimization, caching, faster storage, or backpressure—not just timeouts.

Three corporate mini-stories from the trenches

1) Incident caused by a wrong assumption: “Broken pipe is always client abort”

A mid-size SaaS company upgraded a Debian fleet and noticed more “broken pipe” lines in their API logs. The on-call lead waved it off:
“That’s just people closing tabs.” It was plausible; their traffic was mostly browsers, and the graphs looked fine—at first.

Two days later, a partner integration started failing. Not browsers. Machines. The partner’s batch job opened a connection, posted a payload,
then waited for a response. Their job retried on failure, increasing concurrency. Meanwhile, the API server was slow because a background
compaction job was saturating disk IO. Requests queued. The partner hit its client-side timeout and closed sockets.

The API eventually got around to writing responses to connections that no longer existed. EPIPE flooded logs. The error wasn’t the disease;
it was a symptom of latency long enough to trigger client timeouts. Once retries ramped up, the queue got worse, and now the graphs
were not fine. They were on fire.

The fix wasn’t “suppress broken pipe logs.” The fix was prioritizing foreground IO, moving compaction off peak, adding rate limiting,
and aligning client timeouts with service SLOs. After that, broken pipes dropped to a low, boring baseline—exactly where they belong.

2) Optimization that backfired: aggressive keepalive tuning

At a large enterprise with more proxies than employees (give or take), someone tried to “optimize” connection handling.
The idea: keep connections open longer to reduce TLS handshakes and CPU. So they bumped keepalive timeouts on the reverse proxy and app.

The load balancer in front didn’t get the memo. It had a shorter idle timeout. So the LB quietly dropped idle connections, and the reverse proxy
happily tried to reuse them. Every now and then, a reused connection was already dead. The next write triggered a reset or a broken pipe,
depending on who noticed first.

Worse: the longer keepalive meant more idle sockets. File descriptor usage crept up. During traffic spikes, the proxy hit its fd limit,
started failing accepts, and clients retried. Now you had both unnecessary reconnect churn and resource exhaustion. It was a masterclass
in solving the wrong bottleneck.

The eventual solution was boring and correct: align idle timeouts across LB ↔ proxy ↔ app, cap keepalive requests, and set sane fd limits.
The CPU went up a little. The incident rate went down a lot. That’s a trade you take.

3) Boring but correct practice that saved the day: graceful shutdown and drain discipline

A finance-adjacent platform ran a Debian-based stack behind a proxy tier. They had a culture of “no heroics”: every service had
documented shutdown behavior and an enforced drain process. It sounded bureaucratic until it wasn’t.

One afternoon, a kernel update required reboots. Reboots are where “broken pipe” errors love to breed: connections drop mid-flight,
clients retry, upstreams splutter. But this time, the team followed their own checklist. Nodes were cordoned (or removed from rotation),
traffic drained, long requests were allowed to finish, and only then were services stopped.

In the logs, “broken pipe” barely blipped. More importantly, customer-facing error rates stayed flat. The team still got to go home on time.
The only drama was someone arguing that the process was “too slow,” which is what people say right before the fast way costs them the weekend.

The lesson: draining connections and honoring graceful shutdown windows prevents a surprising amount of EPIPE noise and real user pain.
It’s not glamorous. It works.

Joke #2: The “fast deploy” that ignores draining is like speedrunning a porcelain factory—technically impressive, financially confusing.

Common mistakes: symptom → root cause → fix

1) Symptom: Nginx logs “writev() failed (32: Broken pipe) while sending to client”

Root cause: Client disconnected mid-response (tab closed, mobile network switch, impatient SDK).
Sometimes triggered by slow server responses.

Fix: If normal baseline, reduce log level/sampling for this class; if spike correlates with latency, fix the slowness first.

2) Symptom: App logs EPIPE on writes to upstream (Redis/DB/internal HTTP)

Root cause: Upstream closed connection due to idle timeout, overload, max clients, or restart; or your client reused a stale connection.

Fix: Align keepalive and idle timers, implement retries with jitter (carefully), and confirm upstream saturation metrics.

3) Symptom: Broken pipe spikes exactly during deploys

Root cause: No graceful shutdown, too-short termination window, readiness flips too late, proxy still routes to draining instances.

Fix: Add a drain phase: remove from rotation, stop accepting new work, finish in-flight work, then stop. Tune systemd timeouts.

4) Symptom: Broken pipe + 504 gateway timeouts

Root cause: Upstream too slow or blocked (CPU, IO, lock contention), proxy timeout too short, or queueing.

Fix: Increase timeout only after validating resource headroom. Prefer fixing latency: reduce work, cache, optimize queries, add capacity.

5) Symptom: Broken pipe appears after enabling HTTP response streaming

Root cause: Streaming makes client aborts visible; also proxies may buffer unexpectedly or time out idle streams.

Fix: Configure streaming intentionally: disable buffering where needed, send periodic keepalive bytes if appropriate, tune proxy timeouts.

6) Symptom: Shell command prints “Broken pipe” in a pipeline

Root cause: Downstream command exits early (e.g., head), upstream keeps writing and gets SIGPIPE/EPIPE.

Fix: Usually ignore. If it breaks scripts, redirect stderr, or use tools that stop upstream cleanly (or handle SIGPIPE).

7) Symptom: Many broken pipes after changing keepalive settings

Root cause: Timeout mismatch across layers; reusing dead connections; LB idle timeout shorter than proxy/app.

Fix: Document and align idle timeouts end-to-end; verify with packet capture; roll out changes gradually.

8) Symptom: Broken pipe plus OOM kills or restart storms

Root cause: Process dies while serving requests; peers keep writing to dead sockets.

Fix: Fix memory limits/leaks, reduce concurrency, set sane restart backoff, and implement graceful termination hooks.

Checklists / step-by-step plan

Checklist A: Decide if it’s noise or a fire

1. Where is it logged? Proxy edge logs vs. internal service logs vs. batch scripts.
2. Is the rate changing? Stable baseline is often noise; upward trend is a warning.
3. Are there paired symptoms? 5xx, 504, queue growth, CPU steal, swap, IO latency, retransmits.
4. Is it concentrated? One endpoint, one upstream, one node, one AZ: investigate that slice.
5. Does it align with deploy/restart? If yes, fix draining and shutdown behavior first.

Checklist B: Tighten timeouts and keepalive safely

1. Inventory timeouts at each hop: client, LB, reverse proxy, app server, dependency clients.
2. Pick a target: upstream should time out after downstream, not before (generally), and the LB shouldn’t be the shortest unless intentional.
3. Keepalive idle timeouts must be consistent; if not, expect stale connection reuse.
4. Roll changes to a small subset; watch resets/retransmits and EPIPE rate.
5. Document the “contract” so the next well-meaning optimization doesn’t re-break it.

Checklist C: Make deploys stop causing broken pipes

1. Ensure the instance stops receiving new traffic before stopping the process.
2. Implement readiness that flips early (stop advertising ready) and liveness that avoids flapping.
3. Confirm systemd (or orchestrator) termination grace is long enough for worst-case in-flight requests.
4. Log shutdown phases: “draining started”, “no longer accepting”, “in-flight=…”, “shutdown complete”.
5. Test by deploying under load and measuring client-visible errors, not just log lines.

Checklist D: Reduce broken-pipe noise without blinding yourself

1. Tag logs with context (endpoint, upstream, bytes sent, request time).
2. Sample repetitive EPIPE errors; keep full fidelity for 5xx and timeouts.
3. Keep a metric counter for EPIPE by component; alert on rate-of-change, not existence.
4. Preserve a small raw log sample for forensic work.

FAQ

1) Is “broken pipe” a Debian 13 bug?

Almost never. It’s a standard UNIX/Linux error surfaced by applications. Debian 13 may change versions and defaults, which changes visibility, not physics.

2) Why do I see “BrokenPipeError: [Errno 32]” in Python?

Python raises BrokenPipeError when a write hits EPIPE. It usually means the peer closed the socket (client aborted, upstream timed out, or a proxy cut it).

3) Why does it happen more with Nginx or reverse proxies?

Proxies sit in the middle. They write to clients and upstreams constantly, and they’re the first to discover a peer vanished.
They also log these conditions more explicitly than many apps.

4) Should I disable SIGPIPE?

Many network servers ignore SIGPIPE so a single client disconnect doesn’t kill the process. That’s fine.
Don’t “disable” it blindly in random tools; understand whether you want a crash (fail fast) or an error return (handle gracefully).

5) Does “broken pipe” mean data corruption?

Not by itself. It means a write didn’t reach a reader. If you’re streaming a response, the client got a partial response.
For uploads or internal RPC, you need idempotency and retries to avoid partial state.

6) Why do I see it in shell pipelines when I use head?

Because head exits after it gets enough lines. The upstream process keeps writing and hits a closed pipe.
It’s normal; redirect stderr if it annoys you in scripts.

7) How do I tell whether the client or server closed first?

Use a brief packet capture (FIN/RST direction) or correlate logs: client abort codes (like 499) vs upstream timeouts (504) vs service restarts.
When in doubt, tcpdump for 60 seconds beats arguing.

8) Should I just raise all timeouts to stop it?

No. Raising timeouts can hide overload and increase resource pinning (more concurrent stuck requests, more memory, more sockets).
Fix latency or align timeouts intentionally; don’t just “turn the knobs to the right”.

9) Why does it spike during backups or large exports?

Long-running responses amplify impatience and network variability. Slow IO (disk, object store, database) increases response time, clients time out, then writes hit EPIPE.

10) Is it safe to filter “broken pipe” out of logs?

Sometimes. If you’ve proven it’s mostly client aborts and you have metrics for rate changes, sampling or filtering can reduce noise.
Don’t filter it if it’s tied to upstream timeouts, internal calls, or deploy events.

Conclusion: next steps that reduce noise and risk

“Broken pipe” on Debian 13 is neither a crisis nor a shrug. It’s a clue that one side of a conversation left early.
Your job is to decide whether that early exit was normal behavior, a timeout mismatch, or a system under stress.

Practical next steps that pay off:

1. Classify by source: proxy edge vs app vs internal dependencies.
2. Correlate with timeouts and saturation: if latency or resource pressure rises, chase that first.
3. Align timeouts end-to-end: client ↔ LB ↔ proxy ↔ app, and document the contract.
4. Fix deploy draining: graceful shutdown is cheaper than log forensics.
5. Tame noise without blindness: sample repetitive EPIPE logs, but alert on changes in rate and on paired symptoms (504/5xx/restarts).

The goal isn’t to eliminate every “broken pipe” line. The goal is to make sure the ones that remain are boring, understood, and not the first chapter of case #76.