If ss -ant shows a large and persistent number of Linux connections in FIN_WAIT1, the local host has initiated TCP shutdown and sent a FIN, but that stage of the close has not completed. A brief spike can be normal during traffic peaks, deployments, or batch-job shutdowns. A count that keeps rising, especially alongside timeouts, retransmissions, growing send queues, or ephemeral-port pressure, deserves investigation.
This guide explains what FIN_WAIT1 means, how to identify the process and remote endpoints involved, how to confirm packet loss or delayed acknowledgments, and why common tuning advice such as lowering tcp_fin_timeout often targets the wrong TCP state.
What Does FIN_WAIT1 Mean?
When a local application actively closes an established TCP connection, the kernel sends a FIN and moves from ESTABLISHED to FIN_WAIT1. After the peer acknowledges that FIN, the local socket normally enters FIN_WAIT2. During a simultaneous close, the connection can instead pass through CLOSING before reaching TIME_WAIT.
The important point is that FIN_WAIT1 does not usually mean the application forgot to close the socket. It means the local side has already requested closure, but its FIN has not yet been fully acknowledged. That differs from CLOSE_WAIT, where the local system has received the peer's FIN but the local application has not closed its socket.
First Decide Whether the Count Is Actually Abnormal
Take several samples rather than relying on a single snapshot. A large service may briefly create many FIN_WAIT1 sockets when a load balancer drains an instance, a deployment terminates connections, or a scheduled workload finishes.
ss -s ss -ant state fin-wait-1 watch -n 2 'ss -ant state fin-wait-1 | wc -l' cat /proc/net/sockstat
If the count falls quickly after the workload ends, kernel tuning is probably unnecessary. If it remains elevated or grows continuously, identify the process, endpoints, send queue, and retransmission behavior.
Step 1: Identify the Owning Process
ss -oantp state fin-wait-1 lsof -nP -iTCP | grep FIN_WAIT1
The -p option displays process information when permissions allow, while -o shows timer data. If most sockets belong to one PID, inspect that service's request logs, connection-closing behavior, write timeouts, and recent deployment history. If no process is shown, the socket may be orphaned or the command may lack sufficient privileges.
Step 2: Group Connections by Local and Remote Endpoint
Aggregation helps determine whether the problem is tied to one local service or a particular peer, proxy, NAT gateway, or load balancer.
ss -ant state fin-wait-1 | awk 'NR>1 {print $4}' | sort | uniq -c | sort -nr | head
ss -ant state fin-wait-1 | awk 'NR>1 {print $5}' | sort | uniq -c | sort -nr | headA strong concentration on one remote address points toward that peer or the path leading to it. If many remote destinations are affected but the sockets belong to one local process, investigate the application's shutdown pattern, local congestion, and queued data first.
Step 3: Inspect Send-Q, Timers, and TCP Statistics
ss -iantp state fin-wait-1 ss -oantp state fin-wait-1
Pay attention to Send-Q, retransmission timers, round-trip time, congestion state, and retransmission counters. A Send-Q that remains nonzero indicates that data sent before or alongside the FIN is still waiting to be transmitted or acknowledged. Slow readers, a zero receive window, packet loss, congestion, and applications writing a large amount of data immediately before closing can all extend FIN_WAIT1.
Do not shorten timeouts merely to make the socket count disappear. Faster cleanup can discard data that has not been delivered and turn a visible network symptom into a harder-to-diagnose application error.
Step 4: Capture FIN and ACK Packets
tcpdump -i any -nn 'tcp[tcpflags] & (tcp-fin|tcp-ack) != 0' # Narrow the capture when the peer and port are known tcpdump -i any -nn host 203.0.113.10 and port 443
Confirm four things: whether the local host sends a FIN, whether that FIN is retransmitted, whether the peer returns an ACK, and whether the ACK reaches the local host. Repeated FIN transmissions without a response suggest a peer or network-path problem. If an ACK arrives but the state does not advance, verify the acknowledgment number, connection four-tuple, and whether a middlebox has created inconsistent state.
Common Causes of Persistent FIN_WAIT1 Connections
FIN or ACK Packets Are Being Dropped
Congestion, interface errors, MTU problems, asymmetric routing, or stateful devices can prevent close packets from completing the round trip. Compare packet captures at both ends and check ip -s link, ethtool -S, interface metrics, and retransmission monitoring to locate the loss.
The Peer Is No Longer Responding
The remote process may be stalled, the host may have restarted, or a firewall may silently drop packets after its connection state expires. If the affected sockets are concentrated on a small set of peers, ask the remote side to examine service logs, packet captures, and connection tables during the same time window.
Unacknowledged Data Remains in the Send Queue
An application calling close() does not guarantee that all previously written data has been acknowledged. Large responses, slow clients, receive-window exhaustion, and network backpressure can keep data pending. Review write timeouts, response sizes, client read behavior, and whether the application places unbounded data on slow connections.
A Firewall, NAT Device, or Load Balancer Lost State
A middlebox may remove a flow before either endpoint is finished or may pass packets in only one direction. Useful host-side checks include:
nft list ruleset iptables -S conntrack -S conntrack -L -p tcp 2>/dev/null | grep -i fin_wait
A production conntrack table can be very large, so evaluate the cost before listing every entry. In cloud environments, also inspect security groups, network ACLs, load-balancer idle timeouts, NAT gateway metrics, and route symmetry.
Deployments Create a Shutdown Burst
Terminating many long-lived connections at once can produce a temporary wave of active-close states. A safer deployment drains new traffic first, allows in-flight requests to finish, and only then stops the process. WebSocket, HTTP/2, database-pool, and streaming workloads need a graceful-shutdown window that reflects their real connection lifetime.
Can FIN_WAIT1 Exhaust Ephemeral Ports?
It can contribute to port pressure when the host acts as a client and repeatedly opens connections using the same source-address and destination combination. Check the current ephemeral-port range and overall socket distribution:
sysctl net.ipv4.ip_local_port_range
ss -ant | awk 'NR>1 {print $1}' | sort | uniq -c
cat /proc/net/sockstatThe durable fix is usually to reduce unnecessary short-lived connections, use connection pooling or protocol multiplexing correctly, add client instances or source IPs when appropriate, and resolve the missing FIN acknowledgment. Expanding the ephemeral-port range may provide more headroom, but it does not repair packet loss or an unresponsive peer.
Which Kernel Settings Matter?
Do Not Treat tcp_fin_timeout as a FIN_WAIT1 Cleanup Switch
Linux documentation describes net.ipv4.tcp_fin_timeout primarily as the time an orphaned connection may remain in FIN_WAIT2. It is not a dedicated control for clearing FIN_WAIT1 sockets. Lowering it simply because FIN_WAIT1 is visible often fails to address the actual cause.
Evaluate tcp_retries2 Carefully
net.ipv4.tcp_retries2 influences how long an established TCP connection may continue retransmitting before it is abandoned. A lower value can release connections sooner during prolonged failure, but it can also terminate legitimate connections too aggressively on high-latency, congested, or unstable paths.
sysctl net.ipv4.tcp_retries2 sysctl net.ipv4.tcp_orphan_retries
Record the current values and baseline behavior before changing anything. Test on a limited group of hosts, monitor retransmissions and application errors, and prepare an immediate rollback. There is no universal best value that can safely be copied into every production system.
A Practical Troubleshooting Order
Sample FIN_WAIT1 counts over time and separate short spikes from persistent growth.
Use
ss -oantpto identify processes, endpoints, Send-Q values, and timers.Group sockets by local port and remote address to narrow the affected path.
Capture packets for a known four-tuple and trace FIN, ACK, and retransmissions.
Review application writes, close handling, slow clients, and graceful shutdown.
Inspect firewall, conntrack, NAT, load-balancer, routing, and peer state.
Only after identifying the failure mode, test any kernel change gradually and verify the result.
FIN_WAIT1 Compared with Other TCP Close States
| State | Meaning | Check First |
|---|---|---|
| FIN_WAIT1 | The local host sent FIN but closure has not been acknowledged | Packet loss, peer response, Send-Q, middleboxes |
| FIN_WAIT2 | The local FIN was acknowledged; the host is waiting for the peer's FIN | Peer close behavior and orphaned sockets |
| LAST_ACK | The local host sent FIN after a passive close and awaits the final ACK | Peer ACKs, retransmissions, return path |
| CLOSE_WAIT | The peer sent FIN, but the local application has not closed | Application cleanup and socket leaks |
| TIME_WAIT | Active close is complete while old packets are allowed to expire | Short connections, pooling, and port reuse |
Frequently Asked Questions
Does a high FIN_WAIT1 count mean the server is under attack?
Not by itself. Peer failure, packet loss, queued data, deployment shutdowns, and stateful middleboxes are common explanations. Determine whether an attack is involved by correlating source distribution, connection-creation rate, firewall events, and normal application traffic.
Will restarting the service fix the problem?
A restart may temporarily reduce or redistribute connections, but it will not repair packet loss, an unreachable peer, or an incorrect shutdown strategy. Save ss output, packet captures, and relevant logs before restarting so the evidence is not lost.
Should I lower tcp_retries2 immediately?
No. The setting affects failure detection for established connections and can harm legitimate sessions on slow or unstable networks. First prove that persistent retransmission is the cause, then test a change with monitoring and rollback.
How can I tell whether the local host or the peer is responsible?
Capture traffic at both ends. If the local FIN never reaches the peer, inspect the forward path. If the peer sends an ACK that never returns, inspect the reverse path. If the ACK reaches the local host, verify sequence numbers, the connection four-tuple, and kernel state.
Conclusion
The goal is not simply to remove FIN_WAIT1 sockets. It is to discover why the local FIN is not being acknowledged. Start with ss to identify processes, endpoints, Send-Q values, and timers, then use a focused packet capture to separate peer failure, packet loss, queued data, and middlebox state problems. Consider kernel tuning only after the failure mode is supported by evidence.
References
RFC 9293: Transmission Control Protocol (TCP). Reviewed September 3, 2026.
Linux ss(8) manual page. Reviewed September 3, 2026.
Linux tcp(7) manual page. Reviewed September 3, 2026.
Linux kernel IP sysctl documentation. Reviewed September 3, 2026.
