When ss -ant shows a large number of connections stuck in LAST-ACK on a Linux server, the local application has normally closed its side of the connection and the kernel has sent a FIN, but the final ACK from the peer has not arrived. A few short-lived LAST_ACK sockets are part of normal TCP teardown. The situation deserves investigation when the count keeps increasing, the same peers repeatedly appear, or application errors, connection timeouts, and socket pressure occur at the same time.

This guide explains what LAST_ACK means, how it differs from CLOSE_WAIT, FIN_WAIT1, and FIN_WAIT2, and how to trace the problem from socket counts and processes to packet captures, network devices, and kernel settings.

What Does LAST_ACK Mean?

During TCP teardown, the local host may first receive a FIN from the peer and acknowledge it, placing the connection in CLOSE_WAIT. When the local application later calls close(), the kernel sends its own FIN and moves the socket to LAST_ACK. The connection is removed after the final ACK for that FIN is received.

In practical terms, LAST_ACK means that the local application has completed its close operation, while the kernel is waiting for the peer to acknowledge the final FIN.

First Determine Whether the Increase Is Temporary

Do not draw conclusions from a single snapshot. Monitor the count for several minutes:

watch -n 2 "ss -ant state last-ack | tail -n +2 | wc -l"

You can also summarize all TCP states:

ss -ant | awk 'NR>1 {count[$1]++} END {for (s in count) print s, count[s]}' | sort

If LAST_ACK briefly rises during a traffic spike and then falls, kernel tuning is usually unnecessary. If the count only grows or remains elevated, identify the local ports, remote endpoints, and processes involved.

Step 1: Identify the Ports and Peers

ss -ant state last-ack

# Count remote addresses and ports
ss -Hant state last-ack | awk '{print $5}' | sort | uniq -c | sort -nr | head -20

# Count local addresses and ports
ss -Hant state last-ack | awk '{print $4}' | sort | uniq -c | sort -nr | head -20

If most sockets point to one reverse proxy, load balancer, API gateway, or fixed client, check whether that peer restarted, became overloaded, lost network access, or dropped teardown packets. If the connections are spread across many public addresses, compare them with access logs to identify scanners, malfunctioning clients, or poor network paths.

Step 2: Map the Sockets to a Process

sudo ss -antp state last-ack
sudo lsof -nP -iTCP -sTCP:LAST_ACK

Record the process name, PID, local port, and remote endpoint. Unlike CLOSE_WAIT, LAST_ACK normally indicates that the application already called close. The investigation should therefore include process shutdown behavior, connection teardown timing, peer implementation, and the return network path instead of focusing only on a missing close() call.

For a single affected service, inspect recent logs:

journalctl -u your-service --since "30 minutes ago"
dmesg -T | tail -100

Look for rolling deployments, forced terminations, timeouts, or a sudden burst of long-lived connections being closed.

Step 3: Inspect Timers and Retransmissions

sudo ss -oantp state last-ack
sudo ss -iantp state last-ack

If retransmission counters keep increasing for the same sockets, the host is probably retransmitting FIN without receiving a valid ACK. Common causes include:

• The peer process or host failed and can no longer respond.

• The peer sent ACK, but the packet was lost on the return path.

• A security group, ACL, firewall, or NAT device removed the session too early.

• Load balancers and backends use inconsistent idle timeouts.

• Congestion, asymmetric routing, or connection-tracking problems affect the path.

Step 4: Capture FIN and ACK Packets

The following example captures traffic for a remote peer and local service port 443:

sudo tcpdump -i any -nn -s 0 'host 203.0.113.10 and tcp port 443' -w /tmp/last-ack.pcap

In Wireshark, check whether the local FIN is retransmitted, whether the peer sends ACK, and whether that ACK reaches the correct server. Repeated FIN packets with no response point toward the peer or an intermediate device. If the ACK reaches the interface but the socket remains in LAST_ACK, verify the four-tuple, sequence number, acknowledgment number, NAT translation, and network namespace.

Step 5: Check Firewalls, NAT, and Connection Tracking

sudo nft list ruleset
sudo iptables -S
sudo conntrack -L -p tcp 2>/dev/null | grep -E 'LAST_ACK|src=|dst=' | head

When traffic passes through a cloud load balancer, NAT gateway, or hardware firewall, compare idle timeouts, session persistence, and connection-tracking behavior on both sides. The device dropping the teardown packet may not be the Linux server itself.

Will tcp_fin_timeout Fix LAST_ACK Accumulation?

Usually not. Linux net.ipv4.tcp_fin_timeout primarily controls how long an orphaned connection remains in FIN_WAIT2. It is not a dedicated LAST_ACK timeout. Lowering it does not replace an investigation into missing acknowledgments and FIN retransmissions.

FIN retransmission in LAST_ACK is related to TCP retransmission behavior. net.ipv4.tcp_retries2 influences how long an established TCP connection may retransmit before Linux gives up. However, the setting has broad effects, and an aggressive value can terminate healthy connections during temporary congestion.

sysctl net.ipv4.tcp_fin_timeout
sysctl net.ipv4.tcp_retries2
sysctl net.ipv4.tcp_orphan_retries
sysctl net.ipv4.tcp_max_orphans

Before changing any value, record the existing configuration, socket lifetime, packet loss, and retransmission evidence. Test changes in a controlled environment and keep a rollback plan. Faster socket cleanup may reduce the visible count while leaving the peer or network failure unresolved.

Can LAST_ACK Cause Port Exhaustion?

LAST_ACK sockets consume kernel socket resources. A very large number may increase memory, socket-table, and file-descriptor pressure. Client-side ephemeral-port exhaustion, however, is more commonly associated with large volumes of outbound connections in TIME_WAIT, ESTABLISHED, and related states. Review the broader system state:

cat /proc/net/sockstat
cat /proc/sys/net/ipv4/ip_local_port_range
ulimit -n
cat /proc/sys/fs/file-nr
ss -s

Recommended Troubleshooting Order

1. Monitor the LAST_ACK count and confirm that it is persistent.

2. Group sockets by local port, remote endpoint, and process.

3. Review service restarts, timeouts, and bulk connection shutdowns.

4. Use ss -o and ss -i to inspect timers and retransmissions.

5. Capture traffic and confirm whether FIN leaves and the final ACK returns.

6. Check firewall, NAT, load-balancer, and connection-tracking timeouts.

7. Only then evaluate kernel changes in a test or canary environment.

Frequently Asked Questions

Are a few LAST_ACK sockets normal?

Yes. TCP teardown requires packet exchange, so a small number may appear in any snapshot. Investigate when the count grows continuously, sockets remain for an unusual period, or application failures occur.

Will restarting the service clear LAST_ACK?

A restart may temporarily change or remove some sockets, but it does not prove that the root cause is fixed. Peer failures, packet loss, and mismatched network-device timeouts can make the problem return.

Does a high LAST_ACK count always mean an application bug?

No. The local application has normally initiated its final close by this stage. Application teardown behavior can contribute, but peer failures and return-path packet loss are equally important possibilities.

Should I lower tcp_retries2 immediately?

No. The setting affects TCP retransmission behavior beyond this single symptom. A low value can break valid connections during temporary congestion. Collect packet and retransmission evidence before testing any change.

Conclusion

A large LAST_ACK count does not primarily mean that the local application forgot to close a socket. It means the local host sent its final FIN but did not receive the expected acknowledgment. Start by identifying the affected ports, peers, and processes. Then use socket timers, retransmission counters, and packet captures to determine whether the final ACK is lost at the peer, on the network path, or locally. Kernel tuning should be the final risk-control step, not a substitute for finding the failed teardown path.

References

1. RFC 9293: Transmission Control Protocol (TCP), reviewed September 2, 2026

2. Linux man-pages: ss(8), reviewed September 2, 2026

3. Linux man-pages: tcp(7), reviewed September 2, 2026

4. Linux Kernel Documentation: IP Sysctl, reviewed September 2, 2026