All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
My Unfortunate Experience with Chunkserve
Hi Everyone,
Just wanted to share a quick warning about my recent experience with Chunkserve.
The Setup: LET VM Special (Xeon Gold NVMe) in Amsterdam. Purchased March 9th, 2026.
Intended use case: ERPNext/Frappe development Box.
The Problem: SSH has been fundamentally broken since day one. Initially, it would connect for a few minutes and drop. Now, it outright refuses all connections.
VNC technically connects, but deploying a complex stack like Frappe through a single, un-multiplexed VNC window is practically impossible and incredibly frustrating.
Troubleshooting: To confirm it wasn't user error, I did the following:
* VNC Debugging: Checked sshd_config, ensured the service was running, and completely flushed/disabled all firewall rules (iptables/ufw). No luck.
* Reinstalls: Rebuilt the VPS entirely with Debian 12, Debian 13, and Ubuntu 24.04. The exact same SSH lockouts happened on fresh installs right out of the box.
Support Experience:
I opened a ticket on 13/03/2026 (Ticket #RFE-240395).
As of writing this, it has been completely ignored with zero response.
A VPS without reliable SSH or responsive support is basically a paperweight. Has anyone else had similar routing/lockout issues with this Amsterdam promo?
Thanks for reading.
- What has your recent experience been with Chunkserve?17 votes
- I bought a Similar LET Special and have the exact same SSH/network issues.29.41%
- I have a different Chunkserve plan and it's also having problems.29.41%
- My Chunkserve VPS is actually running perfectly fine.41.18%
Comments
Yep. They are problematic. I have got one server without anything serious. When it works, it is great....when it does not, I am not even ticketing. Sometimes it may reboot and stuck, so I have to manually start it.
SSH runs over TCP and is not too sensitive to network loss.
Have you diagnosed, through packet traces, on why SSH would drop?
In particular, is the SSH drop caused by the operating system, indicating a configuration error possibly from the template, or the network injecting or losing packets?
It works when it's up. Certain steal sometime, but not annoying so, just show up when running
top.About the sometime shutdown without warning that @JohnFilch123 experience, happens to me also. Needed to go to the panel and manually start them. This were annoying when happen, but not often.
As for the (old) cpu, only maybe once or twice (one hand count) max that I use them to the full, as long as I remember. For network connections, it works normally as can be expected. I only use shell cli & left the down&up speed up to the mercy at that time & mostly left them work in the background (never disconnect while they were running).
My take on your situation, maybe the network latency were the problem (the vnc). As for the ssh, didn't know how that can be happened. Usually the disconnect were caused by my inet provider on my case, never on the vps network side.
I didn't notice any problems
When we had Wi-Fi problem at the apartment, ping latency is 2000ms and packet loss is 10%, but SSH still works.
For network issue to break SSH, it would need even higher latency, or network needs to inject RST (often from Intrusion Detection System).
@The_Sage do you have another VPS to test long standing connections with? It could be a NAT/conntrack issue on your side/by your ISP (i.e. you router/CGNAT changing the source port).
Install tcpdump on the chunkserve node, note what source IP+port the packets are coming from (
tcpdump -envi any tcp port 22) and when SSH hangs, connect via VNC, run the same command over the VNC console and when you press a key in the now hanging ssh session, see if it matches what you noted before.Another command to troubleshoot such issues is conntrack.
Good luck!
If you have another VPS somewhere, try to SSH from there. Not as a permanent solution, but to see if it makes any difference. Your issue may not be with the SSH config. I have a ChunkServe VPS, and although it's not ideal for several reasons, I don't experience problems with SSH.
Another hint: don't use AI for your post next time
It needs to be confirmed whether the issue is ssh specific or general network outage. If it's ssh only, that's a you problem. If it's the network, that's a provider problem.
Not necessarily. I'd say:
My NAT idea could affect any other protocol beside SSH too.
Post traceroute.
Also consider using Mosh instead if the issue is packet loss.
I ordered vps and vps every time down after some time, open ticket some days ago but dont answer. ((((
To be honest, this is my first time using your services. I have worked with several other hosting providers in the past, and I have never encountered this level of instability right out of the gate.
Actually yes i have 2 production vps servers from another provider and everything is working well over there
I initially had the exact same thought. However, after testing the connection alongside my other VPS servers, I can confirm the problem isn't on my end. I suspect the issue might be isolated to specific nodes on their network.
Thanks for the tip, I'll definitely give Mosh a try. However, basic SSH shouldn't be fundamentally broken on a VPS, regardless of how good the deal is. I actually posted a traceroute in one of the comments showing packet loss. I initially thought it might be an issue with my ISP—even though my other servers are working perfectly fine—so I ran a test using an external online traceroute service to rule that out. That's the result I posted here.
Last hop seems to have 0.0% packet loss though
We can only analyze .pcap files, uploaded as they were captured.
We do not analyze pictures or text outputs.
Not SSH, just service generally. Today, I am experiencing the second major outage. Now billing.chunkserve.com is offline in CF. Before, I could get to the panel and attempt to start my VPS, which failed, and could open a ticket. Now, nothing. Sad. I think the owner is NOT trying to scam anyone. But, just out of his depth. I wish he would get some technical help - there is a lot out there, including many members of this forum.
Just using another protocol is IMHO not a solution. You might manage to deploy your stuff, but your users might still suffer. Difficult to say though.
Long SSH sessions working with other providers tells me that it isn't your NAT just forgetting the session and changing the source port.
Is there a difference in behavior with IPv6/IPv4?
I have a VPS with them in AMS for a month and while I've never had any issues, and its the third redundant instance, I'm not really trusting it...
Yeah same problem billing down
How exactly could a VPS be used as a paperweight?
Take the server, run it through a reinforced bread slicer, take home one of the pieces.
Ok, so listen. A packet needs either electricity, or light to exist, right? So it has to have energy. And energy can't be destroyed. So when a packet gets lost, what happens to its energy?
I'll tell you: E=mc^2. All the lost packets become a paperweight!
It can't, that's the the problem. Everybody needs a good paperweight but this one is pretty useless as is.
To me the best option is to create an NFT for this VPS and record it on a blockchain, then sell it for a profit.
I sometimes hear people complain that their VPS has a heavy load, so surely it must be able to be used as a paperweight, right?
Tip: Don't use the highlighter feature if you want to hide something. I can read the IP easily, 143.20.xx.xxx
Copy and paste into a code block. Ain't nobody got time for tiny ass screenshots.
Into the white space of shitty screenshots.
As per the OPs provided screenshot, there's a lot of lost packets there.
@The_Sage
My @Chunkserve VPS works fine and reliably (just tested again). SSHing into it works perfectly fine and quick. Btw uptime is high as well.
SSH problem tend to be "you" problems as in "your VPS". The very rare problems I ever experienced so far could all be recognized via adding '-v' to the call (and basically always it turned out that I had a typo in either the server's or the client's config).