All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
DediRock VPS became inaccessible, support suggested reinstall without explaining cause
Recurring access issue with DediRock VPS, support suggested reinstall without explaining the cause
Hi everyone,
I want to share my recent experience with a DediRock VPS and ask whether anyone else has seen similar issues.
I have been using this VPS for about two months. The server is hosted on ColoCrossing infrastructure as far as I know. I have also purchased similar ColoCrossing-based servers directly before, and the same type of configuration usually costs around $10. With DediRock, I saved about $3, so I understood there might be some trade-off.
The VPS had been stable for roughly two months, but today it suddenly became inaccessible.
What I observed:
- SSH on my custom port still accepted TCP connections, but closed before key exchange.
- HTTP/HTTPS and my control panel ports did not respond normally.
- In the DediRock client area, reboot and shutdown actions redirected to a 404 page, so I could not power-cycle the VPS myself.
- My Cloudflare Access page was still reachable, but the origin server could not be confirmed as healthy.
I opened a ticket and described the issue in detail. Support replied fairly quickly, which I appreciate. However, they did not explain what actually went wrong. They only said that reinstalling the operating system was the most effective solution and warned that it would wipe all existing data.
I understand that small providers and startups may have limited support resources, so I agreed to the reinstall in order to restore access as quickly as possible. However, after confirming that they could wipe the data, the handling and follow-up have not been as timely as I hoped. At the moment, I am still waiting for the final result.
My personal feeling is that this does not look like a normal guest OS issue. Since the client area power controls also returned 404, and SSH closed before key exchange, it feels more like something related to the provider side, such as the node, network, public IP mapping, or control panel backend.
I am not posting this to attack anyone. I just want to document the experience and ask:
- Has anyone else had similar recent issues with DediRock?
- Is reinstalling the OS a common first solution from them?
- Would it be more reasonable to ask for migration to another VPS with the same specs if the issue might be node/network related?
I will update this thread once I get the final result.
Comments
they are super-low end. if you have $7/yr VPS then its DIY troubleshoot. can't expect more from provider.
I understand the low-end nature of the service, and I am not expecting managed support.
I am not asking the provider to troubleshoot my application, configure my firewall, or manage my server for me. I already accepted data loss and confirmed an OS reinstall in order to restore access quickly.
The issue I wanted to document is different:
For a $7/year VPS, I agree that users should do most troubleshooting themselves. But basic platform access, working power controls, and a clear response about whether the node/control panel is broken are still provider-side responsibilities.
That is exactly my point.
I fully understand this is a low-end unmanaged VPS, and I was not asking them to troubleshoot my application or manage the OS for me.
My first attempt was to DIY the recovery myself. I tried to reboot or power cycle the VPS from the client area, but the reboot/shutdown actions redirected to a 404 page. There was also no usable VNC/console access available. SSH accepted TCP connections but closed before key exchange, so I had no working access path at all.
So the issue is not “I expected managed support on a cheap VPS”.
The issue is that the basic self-service recovery tools were not working. If the provider expects users to troubleshoot everything themselves, then the provider still needs to provide working power controls, console/rescue access, or at least explain why those are unavailable.
I accepted a full reinstall and data wipe because I wanted to restore access quickly, not because I expected them to manage the server for me.
@DediRock
One final clarification, then I will stop debating the price argument.
The timeline and the issue were already clearly described in the original post.
I did not ask the provider to manage my server, debug my application, configure my firewall, or do anything that I could reasonably do myself from inside the VPS.
My first choice was to fix or recover it myself. But SSH was not usable, the client area reboot/shutdown actions returned 404, and there was no working console/VNC/rescue access available to me. In that situation, there was no practical self-service path left.
So repeating “it is cheap” does not address the actual issue.
Cheap unmanaged VPS means I should not expect managed support. I agree with that.
It does not mean broken power controls, no recovery console, no explanation, and no timely follow-up after accepting a full data wipe are automatically acceptable.
If someone still wants to argue only from the price, please understand that this is not the point of the thread.
lowenddrama 🍿
Outside of the reboot page being 404 this might be an MTU issue. If you haven't changed your local configuration lately its rather unlikely but its an option.
Edit: If you don't get VNC to access to your VPS exactly in case of network problems you should probably expect that reliability of the box will be low and putting anything important on it is just a question of when not if shit is going to hit the fan.
Thanks, MTU is a fair point and I agree it could explain some strange SSH/TLS/network behavior.
However, in my case there are two additional issues:
I also had not changed my local network configuration recently.
So yes, MTU could be one possible technical cause for part of the symptoms, but the lack of working self-service recovery tools is still the main issue for me.
And I agree with your second point: without VNC/console access, this box is not something I should rely on for anything important.
Update:
DediRock replied and provisioned a fresh VPS to replace the problematic one. The new server is now installed, and I can log in successfully.
The IP address changed, so this appears to be a replacement VPS rather than only an in-place OS reinstall. The new VPS is located in Buffalo, New York, and the reverse DNS still points to ColoCrossing infrastructure.
For now, the immediate access issue has been resolved. I did not receive a detailed explanation of the original cause, so I will continue to monitor stability over the next few days.
I am sharing this update mainly so future users can have more information when evaluating the service. Support did respond and eventually restored access by replacing the VPS.