I don’t know where to begin with this. Basically, I have a problem. Actually, Hostinger has the problem. I started noticing the Hostinger FTP problem on May 30th, 2024. I’ve since caught on to the pattern and found that this bug happens between 1:30 AM to 2:00 AM every day. It’s an odd problem. I can login successfully during this time, but the FTP server fails to open a channel to send me a directory listing. Everyday. I’m a night owl. I’m making changes, testing things, and BOOM! The build server tells me that it failed to deploy.
This happens with multiple FTP accounts, multiple types of FTP software, and from multiple locations, including my home. The problem stems specifically when a request is made for a list of files in the directory.
From what I’ve gathered talking with multiple support staff over the past few weeks is:
- No maintenance is scheduled on the server
- Nothing shows up in the FTP logs
- The FTP server is online (yea, I could have told them that)
- They operate in UTC time, so its between 4 and 5 AM for them
- Technical staff are unavailable to troubleshoot during this window
- No one has been able to confirm that they attempted to log into the server to verify the issue during this time frame
My recommendation was to setup an automated task to log into the server during this timeframe, request a list of files, and save it to a log. At least this would trigger the error that I keep seeing and they could confirm its existence without having to wake up early in the morning to verify. I suspect something is happening in this timeframe, such as a maintenance task, that is blocking a port, or a range of ports that the FTP server would open to send the directory listing to an FTP client.




FTP Troubleshooting Prompt: Microsoft Designer
demonstrate an FTP that has a problem sending a list of files in a directory. Furthermore, show that an Artificial Intelligence chat bot is incapable of providing anything meaningful to resolve the problem, and that a human eventually gets involved to aid with limited technical support. Given that its so early in the morning, the “real” technical support staff are unavailable to troubleshoot the problem that only occurs between 1:30 AM and 2:00 AM.
When I first confirmed this problem, my FTP client (FTP Rush) would respond that the specified data channel type is not implemented.
[2][FTP]Status: Start Login dev-api.periplux.io ... [2][FTP]Status: Connecting to 194.164.64.119:21 [2][FTP]Status: Text encoding: System.Text.UTF8Encoding [2][FTP]Status: Login dev-api.periplux.io Successfully [2][FTP]Status: Start List directory / ... [2][FTP]Error: The specified data channel type is not implemented
For context, here is a verbose FTP log using FileZilla.
01:51:50 Status: Logged in 01:51:50 Trace: Measured latency of 24 ms 01:51:50 Trace: CFtpControlSocket::ResetOperation(0) 01:51:50 Trace: CControlSocket::ResetOperation(0) 01:51:50 Trace: CFtpLogonOpData::Reset(0) in state 15 01:51:50 Trace: CFileZillaEnginePrivate::ResetOperation(0) 01:51:50 Trace: CControlSocket::SendNextCommand() 01:51:50 Trace: CFtpListOpData::Send() in state 0 01:51:50 Status: Retrieving directory listing... 01:51:50 Trace: CFtpChangeDirOpData::Send() in state 0 01:51:50 Trace: CFtpChangeDirOpData::Send() in state 1 01:51:50 Command: PWD 01:51:50 Trace: tls_layer_impl::on_read() 01:51:50 Trace: CFtpControlSocket::OnReceive() 01:51:50 Response: 257 "/" is the current directory 01:51:50 Trace: CFtpChangeDirOpData::ParseResponse() in state 1 01:51:50 Trace: CFtpControlSocket::ResetOperation(0) 01:51:50 Trace: CControlSocket::ResetOperation(0) 01:51:50 Trace: CFtpChangeDirOpData::Reset(0) in state 1 01:51:50 Trace: CFtpListOpData::SubcommandResult(0) in state 1 01:51:50 Trace: CControlSocket::SendNextCommand() 01:51:50 Trace: CFtpListOpData::Send() in state 2 01:51:50 Trace: CFtpRawTransferOpData::Send() in state 0 01:51:50 Trace: CFtpRawTransferOpData::Send() in state 1 01:51:50 Command: TYPE I 01:51:50 Trace: tls_layer_impl::on_read() 01:51:50 Trace: CFtpControlSocket::OnReceive() 01:51:50 Response: 200 Type set to I 01:51:50 Trace: CFtpRawTransferOpData::ParseResponse() in state 1 01:51:50 Trace: CControlSocket::SendNextCommand() 01:51:50 Trace: CFtpRawTransferOpData::Send() in state 2 01:51:50 Command: PASV 01:51:50 Trace: tls_layer_impl::on_read() 01:51:50 Trace: CFtpControlSocket::OnReceive() 01:51:50 Error: Connection closed by server 01:51:50 Trace: CRealControlSocket::DoClose(66) 01:51:50 Trace: CControlSocket::DoClose(66) 01:51:50 Trace: CFtpControlSocket::ResetOperation(66) 01:51:50 Trace: CControlSocket::ResetOperation(66) 01:51:50 Trace: CFtpRawTransferOpData::Reset(66) in state 2 01:51:50 Trace: CFtpControlSocket::ResetOperation(66) 01:51:50 Trace: CControlSocket::ResetOperation(66) 01:51:50 Trace: CFtpListOpData::Reset(66) in state 3 01:51:50 Error: Failed to retrieve directory listing 01:51:50 Trace: CFileZillaEnginePrivate::ResetOperation(66)
The first time I encountered this issue, my build server was in an infinite hang state. Thankfully I had thought ahead and added a timeout to my build script. I later changed the build servers deployment job to use a different FTP package (SamKirkland/FTP-Deploy-Action@v4.3.5). During this timeframe, the package wouldn’t see any files on the FTP server. As soon as it attempted to upload a file, the connection failed.
Making changes to 1404 files/folders to sync server state
Uploading: 5.35 MB -- Deleting: 0 B -- Replacing: 0 B
----------------------------------------------------------------
creating folder "common/"
----------------------------------------------------------------
-------------- 🔥🔥🔥 an error occurred 🔥🔥🔥 --------------
----------------------------------------------------------------
----------------------------------------------------------------
---------------------- full error below ----------------------
----------------------------------------------------------------
Error: Client is closed because Server sent FIN packet unexpectedly, closing connection.
at /home/runner/work/_actions/SamKirkland/FTP-Deploy-Action/v4.3.5/dist/index.js:5208:29
at new Promise (<anonymous>)
at FTPContext.handle (/home/runner/work/_actions/SamKirkland/FTP-Deploy-Action/v4.3.5/dist/index.js:5190:16)
at Client.sendIgnoringError (/home/runner/work/_actions/SamKirkland/FTP-Deploy-Action/v4.3.5/dist/index.js:4226:25)
at Client._openDir (/home/runner/work/_actions/SamKirkland/FTP-Deploy-Action/v4.3.5/dist/index.js:4753:20)
at Client.ensureDir (/home/runner/work/_actions/SamKirkland/FTP-Deploy-Action/v4.3.5/dist/index.js:4744:24)
at /home/runner/work/_actions/SamKirkland/FTP-Deploy-Action/v4.3.5/dist/index.js:3555:126
at Generator.next (<anonymous>)
at /home/runner/work/_actions/SamKirkland/FTP-Deploy-Action/v4.3.5/dist/index.js:3540:71
at new Promise (<anonymous>)
Closing reason: Error: Server sent FIN packet unexpectedly, closing connection.
at Socket.<anonymous> (/home/runner/work/_actions/SamKirkland/FTP-Deploy-Action/v4.3.5/dist/index.js:5109:56)
at Socket.emit (node:events:531:35)
at endReadableNT (node:internal/streams/readable:1696:12)
at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {
code: '0'
}
Error: Error: Client is closed because Server sent FIN packet unexpectedly, closing connection.
After a few reports, the support staff opened ticket #97118. I’m unable to see the contents of this ticket, make comments, or add screenshots. All I can see is that it is in progress. Clicking on the button to view the conversation takes me to the original conversation, but any reply to it just opens a new conversation to talk with the AI bot.

Talking with the AI bot is fairly frustrating. Often times it goes through repeated steps of how to configure FTP and change to passive mode, or suggesting its an issue with my router or ISP. A few times it was trying to tell me that I didn’t have the ftp subdomain setup as a website. When I reference the ticket, it often gives me responses that it can’t view or interact with the ticket, I should make comments on the ticket, or respond in email. That’s not how their system works. I keep trying to rephrase my prompts so that it could get into contact with support staff in the hope that they’ll be able to respond quick enough to verify that the issue is still present before 2:00AM rolls around. Today, I was able to reduce the paging of support staff down to 2 minutes.
The FTP server is responding oddly again. Please tell the support staff that the FTP server is failing to send directory listings over a separate port again. It’s 1:36 AM Eastern. This always happens between 1:30 and 2:00 AM. This is directly related to my support ticket #97118.
It sounds like you’re experiencing issues with the FTP server. However, I specialize in website-related issues. For FTP server problems, it would be best to refer to the specific support ticket you mentioned or check for updates directly related to that issue. If you have any website-related queries, feel free to ask!
I don’t care what the AI specializes in… I need support. Their are no other subjects that come close to choose from in regards to FTP. The ticket doesn’t report updates.
I don’t have access to view that ticket or add any additional comments or screenshots of the issue. Please inform support staff so that they can log that it is still happening.
I’m here to assist with website-related issues, and I don’t have the capability to access or update support tickets directly. For issues related to FTP or support tickets, please refer to the appropriate channels within the Hostinger panel where you can manage and view your support tickets. If there’s anything else related to your website that you need help with, please let me know!
Again, they need to stop with the website-related issues mantra. I just need a human that can understand what I am saying to confirm what is going on and update the ticket.
Again, I don’t have access. Please contact support and let them know.
I’m now redirecting you to our Customer Success Team for further assistance. A specialist will join our conversation shortly. They’ll have access to our chat history, so there’s no need for you to repeat anything previously mentioned, unless you’d like to provide additional details.
Finally…
Tonights change included a detailed log with debugging of my FTP client during this window. The support staff thought I had a new issue since it was a different error. I had to clarify that the first screenshot she provided was from a different FTP client (FTP Rush), and the second screenshot was from the second FTP client (FileZilla), but without debug logs. I installed FileZilla at their recommendation.
The resolution at the end of the day was to change to a new server. Out of the list that she provided, Arizona seemed to be the closest at 1,000 miles, and the only one within the country. (My current server is in Massachusetts). It’s at no cost to transfer, and she was willing to do it for me so that I didn’t have to wait the full 30 days since my account was first created. I now have four hours to wait until the transfer completes.
She also gave me some information regarding the refunding my account. Since I also purchased a domain name, the account would have to be manually refunded via technical support, and the domain itself would not be refunded since it was past the four day refund window. I would only be refunded for the cost of the website. The domain name would still stay at hostinger and me managed their unless I decided to transfer it to another host. That’s understandable. I thought the company was going to give me a story where I couldn’t refund anything at all and just keep the cash.
So far my experience with hostinger is unpleasant. The AI is horrible and likes to give bad information – even when I was a prospective client, it gave me inaccurate information. Its difficult to navigate the site/AI in order to talk to a human. I can’t view tickets. I can’t blindly add notes/screenshots to tickets. After several weeks of a repeat occurrence, the company hasn’t thought to either automate a task to confirm the behavior, or ask someone to test that this problem exists.
With all of the incidents reported over the past few weeks, the help page says that no incidents were reported over the past five days. Reviewing all of the components on the status page, FTP services was not found and my server name or number wasn’t found either.

What about everything else?
Well… I haven’t had much problems. Actually I have had a few, but they are small issues. Setting up Secure FTP seems to be a problem. The MariaDB database isn’t configured to allow encryption on the file system or connections to it. MariaDB isn’t setup with the latest AES encryption functions to allow for different block algorithms. I can’t create multiple database accounts for the same database, and restrict them so that the web account can only call stored procedures. They are using a legacy version of memcache instead of memcached. It’s not clear if the performance dashboard of the server is for my account only, or for all accounts that are using the server. No access to FTP logs. There are small differences in the SQL that MariaDB supports vs MySQL when it comes to exiting procedures or working with transactions. The precision of CRON jobs is limited to “every” or a specific weekday, month, day, hour, or minute. Actually, minutes are more granular as I can choose every 2nd, 5th, 10th, 15th, and 30th minute. However, I can’t choose to run a job every three months, or on the 1st and 15th of the month. Instead, I would have to setup multiple jobs. The chat bubble for support often shows that a message is waiting, or keeps making a small sound to call itself to attention – but their are no new conversations. It would be preferable if they offered a service to manage secrets, environment variables, and/or encryption keys outside of the file system and database. On top of that, I keep getting several messages throughout the day that a new hPanel version is available and that I should reload for the best experience.

All of this is just small potatoes. However, it’s adding up over time. The main thorn in my side is currently the FTP server being unable to send directory information from 1:30 AM to 2:00 AM. Every day. Again, and again. This leads me into at least a 30 minute window of frustration of dealing with the AI chatbot, which then leads into trying to convey information to the support staff.
I keep getting side tracked troubleshooting this weird issue instead of working on code. It’s a daily hassle. I feel like I’m burning too much time to troubleshoot an automated task that causes a configuration error on their side for 30 minutes each day. Is this because I was too cheap with the plan I choose? Would other shared hosting plans have the same issue? What about a virtual server?
Yea, yea… I keep griping.
So what do you like?
The interface seems clean and simple. I like that I can setup cron jobs. I like that I can use the latest version of PHP and use typed variables in my function arguments. Managing PHP extensions is a breeze as you simply click a checkbox to enable/disable extensions. I can setup an FTP account so that it only has access to a specific sub-domains folder. I can setup multiple FTP accounts. I like that I can click CTRL+S to save files in their web-based file manager. I love that I can drag and drop files and directories from my operating systems desktop into the web page to upload. I like that I can name the folders that my sub-domains reside in, and by default, the folders are named after the sub-domain. I like that I can use most features that more recent versions of MySQL introduced.
Transfer Completed
Well… looking at my email, it looks like the transfer had completed in under a minute. I wonder why they said that my hPanel would be locked out during a four hour window.

And it looks like it transferred in 7 seconds.

And from here, they are now suggesting that I don’t touch anything for 24 hours.

The big question is… did this solve the problem? The soonest that I’ll find out is 1:30 AM Tuesday morning.
Are you walking away?
Not yet. I need to confirm if this issue still exists on the new server/datacenter. If the problem goes away, or staff are able to confirm/verify that a problem does indeed exist, that would change things.
I don’t like it when I have a weird, uncommon problem that people could confirm if they did a simple check for themselves within a short window. ie – log into an FTP server to see that it fails to list files. I don’t like it when support staff treat the issue as if it were something else that the user could resolve on their own. Furthermore, I don’t like it when people are told exact details (consistent time and reproduction steps), and an effort is not made to verify either manually or through automation. I don’t like it that staff are not reaching out to report if anyone actually looked at the problem, ask for details, test it themselves, or report the absence of a problem. There is no communication other than the first line of help staff. It feels like it’s a one-way conversation without any feedback from the people who are able to look at the problem directly. In addition, I have a 30 day window coming to an end to close my account and get a refund if the problem doesn’t resolve itself.

3 responses to “Troubleshooting Hostinger”
[…] a side note about the Hostinger FTP problem, I did log in shortly after 1:30 AM with a few FTP clients and confirmed that I was able to get […]
[…] do not transfer when changing servers. I’ll add that to a list of grievances that I have with Hostinger. On a side note, I haven’t experience the FTP errors recently. Once I turned on memcache, I […]
[…] June 17: Troubleshooting Hostinger […]