A TTL of 54 makes sense. You’re about 10 hops away from the server and 64 is a common TTL default value. That definitely looks like the server closed the connection, either on purpose or the server process crashed and the operating system closed the TCP socket.

(The RST after the FIN looks like an effect I’ve seen before (on Linux): if a TCP socket is closed while there is still data in the receive buffer, or data arrives after the FIN has been sent, a RST is sent to let the other side know that not all data received was delivered to the application. In your case the last two chunks of data (336 bytes sent at 205.284423 and 112 bytes sent at 205.296661 were not acknowledged by the server.)

Everything up to the FIN looks fine: timely ACKs for received data from both sides and window sizes are in the green. I don’t see anything going wrong here. Of course we don’t know anything about the actual data being exchanged and whether it conforms to whatever application layer protocol FF XIV uses. The only thing different (compared to your other screenshots) is that this screenshot only shows data from one TCP connection — due to your filter (tcp.port eq 58899 and tcp.port eq 55026) — whereas your other screenshots showed that there are actually two TCP connections involved, both to port 55026 on the server. I have no idea why a FF XIV client needs/has two TCP connections to the same port on the server.

I’d say it’s time for someone from Square Enix or the data center to ask you for the exact timestamp of a FIN from your Wireshark capture so they can have a look at the server’s log and figure out why the heck the server closed the connection. To keep pointing fingers at a customer’s ISP doesn’t cut it this time IMHO…

PS: Thanks to https://convertio.co/ocr/ for their nice online OCR service . Worked like a charm on your screenshots.