New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
We sincerely apologize for your experience and for the generic response to your ticket without checking your VPS status. We understand your frustration with the network instability and the time you’ve lost. We’re reviewing the situation and will ensure your cancellation and any applicable refund are handled appropriately.
After your comment , received the prize . Maybe he's been tied up with something urgent.
To be honest, I am really disappointed with Servitro; it’s essentially a gamble every single day as to whether or not you can actually use the server.
The server is offline yet again (well, at least this time Servitro managed to send a notification via email).
Overall, I have to say that the support, performance, and availability are truly disappointing.
Having to wait two days or more for a response to a support ticket is, in my view, far too long.
I can certainly understand that things can occasionally break or that a server might go down, but the outages and lack of availability at Servitro are becoming increasingly frequent.
I cannot recommend Servitro under any circumstances.
Yes, I saw that.
Yes, me too.
In my opinion, the fact that servitro has posted here again has more to do with the forum administrator’s threat of consequences.
Thank you very much, I’ve received it.
I understand that you may be busy with other matters, but it would be appropriate to at least provide your customers with regular updates.
Hi everyone,
Has anyone else been experiencing IPv6 connectivity issues with Servitro recently?
I'm experiencing inconsistent IPv6 connectivity to my VPS. Outbound IPv6 connectivity works correctly, but incoming connections from certain external networks fail.
During testing, I confirmed that TCP SYN packets from my client reach the VPS, and the server responds with SYN-ACK packets, but the final ACK never arrives. This happens when connecting via SSH (port 22) and to a temporary test server running on port 8080.
Interestingly, SSH over IPv6 works from another external VPS. This suggests that the issue may be related to the source network or routing between networks.
I also tested IPv6 connectivity using monitoring probes around the world. Here are the results.
Successful tests — 0% packet loss (10/10):
Frankfurt, Germany — Constant Co. (AS20473), average 1.962 ms
Sandefjord, Norway — Gigahost (AS56655), average 27.201 ms
Miami, USA — Constant Co. (AS20473), average 275.736 ms
North Charleston, USA — Google (AS396982), average 99.195 ms
The Dalles, USA — Google (AS396982), average 157.490 ms
Dallas, USA — Constant Co. (AS20473), average 174.618 ms
Toronto, Canada — Constant Co. (AS20473), average 92.176 ms
Taipei, Taiwan — Google (AS396982), average 250.621 ms
Failed tests — 100% packet loss (10/10):
Sydney, Australia — Constant Co. (AS20473)
Johannesburg, South Africa — Constant Co. (AS20473)
Santiago, Chile — Constant Co. (AS20473)
Santiago, Chile — Oracle Cloud (AS31898)
Stockholm, Sweden — AWS (AS16509)
Stockholm, Sweden — Constant Co. (AS20473)
Warsaw, Poland — Scaleway (AS12876)
Zurich, Switzerland — Oracle Cloud (AS31898)
Houston, USA — Ezee Fiber (AS35847)
Seattle, USA — Constant Co. (AS20473)
Council Bluffs, USA — Google (AS396982)
Bangkok, Thailand — Advance Wireless Network (AS131445)
Singapore — Constant Co. (AS20473)
Singapore — Akamai Connected Cloud (AS63949)
Cebu, Philippines — Globe Telecom (AS4775)
Tokyo, Japan — Oracle Cloud (AS31898)
Tokyo, Japan — Constant Co. (AS20473)
Traceroute tests also showed different results depending on the source network. Some routes stopped responding at Cogent network nodes in Frankfurt, while the VPS was reachable from other locations.
I understand that failed ping tests alone do not necessarily indicate a TCP connectivity problem, as ICMPv6 traffic may be filtered. However, combined with the failed TCP handshakes and the packet captures taken directly on the VPS, these results make me suspect that further investigation is needed.
I've opened a support ticket with Servitro and asked them to investigate IPv6 routing, the return path, and any possible network-level filtering.
Has anyone else experienced similar IPv6 connectivity issues with Servitro? I'd also be interested in hearing about experiences connecting from different networks and regions.
Thanks!
They are currently making a big, big mess of things.
To my VPS with them, IPv6 has been offline to quite a number of locations for a couple of days now. It's partially restored (after a ticket and quite a long wait), but in the meanwhile IPv4 also is starting to fail, came back, and is failing again. Routing is terrible at this moment, most locations cannot reach the VPS.
In the meanwhile they seem to have installed some kind of AI-ish powered handling for tickets because I get replies on tickets that give standarised answers and even are delusional at times.
来了来了
The IPv6 issue was resolved yesterday, and it shouldn't happen again.
"Resolved" - maybe that particular issue but in the meanwhile IPv6 is only reachable from a few hosts on the internet (according to a ping.pe test: only 5 of the hosts can reach my IPv6 address. Tested just now) and IPv4 is flaky as hell.
Just launched a VPS and already got horrible packet loss that I didn't saw on test looking glass ip 5.231.106.125.
SZV-411102 2 days ignored
I performed another IPv6 connectivity test. The latest results show that the server responds from 23 out of 25 test points across Europe, North and South America, Africa, Asia, and Australia.
✅ Working locations (23 test points)
❌ Non-responsive locations (2 test points)
Summary
A couple of interesting observations:
These results suggest that IPv6 connectivity may vary depending on the source network and the location from which the connection is tested.
Note: These results are based on ICMP/ping tests only. They do not necessarily confirm SSH or other service availability from every location.
I'll continue monitoring IPv6 connectivity and share further updates if the results change.
Yeah, after 3 days of issues on IPv6 it is restored. For the rest (IPv4 and IPv6) it's packet loss galore today.
@Servitro Thank you for your previous public response.
As requested, I sent my support ticket ID to you by DM so that my case could be prioritized. Unfortunately, I have still received no response to the DM and no substantive update in the support ticket.
On October 19, your support team stated that my refund request had been forwarded to the finance team. I followed up again on October 20, October 21, and October 22, but I still have not received confirmation of the refund amount or processing date.
The service has already been cancelled.
Could you please provide a concrete update on the refund and an expected processing date?
I would prefer to resolve this directly with Servitro, but if there is still no substantive response, I will have to proceed with a formal payment dispute and provide the complete correspondence as evidence.
I will update this thread when the matter is resolved.
I cancelled my yearly promo plan a few months ago because the network was simply too poor to be usable.
I still had about six months left on the plan, but no refund was offered for the unused time.
sue them Jack !!
[Review & Benchmark] Servitro $20/yr Special (Frankfurt/London) – 2 vCPU AMD EPYC 7T83, 4GB RAM: Steal Time & Stability Reality Check
Executive Summary & Use Case
System Specs & Environment
Processor : AMD EPYC 7T83 64-Core Processor (2 vCPU cores @ 2.45 GHz)
RAM : 4.0 GB (3.8 GiB usable) + 1.5 GiB Swap
Disk : 48.4 GiB NVMe / SSD (/dev/vda1)
Virtualization : KVM (Full AMD-V / SVM enabled, AES-NI enabled)
OS / Kernel : Ubuntu 26.04 LTS / Linux Kernel 7.0.0-38-generic
Network : Dual-stack IPv4 & native IPv6
1. CPU Steal Time & Stability Analysis (sar Historical Data)
Day-by-day average steal time extracted directly from the system's sysstat/sar logs (October 14 – October 22, 2026):
Date %user %system %iowait %steal %idle
2026-10-14 0.02 0.35 0.01 0.14 99.48
2026-10-15 0.22 0.42 0.20 0.11 99.03
2026-10-16 0.34 0.29 0.06 0.20 99.11
2026-10-17 0.06 0.16 0.01 0.21 99.56
2026-10-18 0.02 0.15 0.01 0.28 99.54
2026-10-19 0.41 0.52 0.71 0.56 97.80 (minor temporary bump)
2026-10-20 0.09 0.42 0.01 0.13 99.34
2026-10-21 0.03 0.41 0.01 0.10 99.44
2026-10-22 0.81 0.63 0.45 0.15 97.95
8-Day Steal Average: ~0.15% (Virtually negligible!)
Note: Even during 100% CPU load across both cores during the Geekbench 6 test, vmstat reported 0% steal time (st: 0), demonstrating that the CPU allocation is isolated and stable.
2. Disk Performance (YABS fio Benchmark)
Random Mixed Read/Write 50/50 test on partition /dev/vda1:
3. Network Throughput & Latency (iperf3 & ICMP)
Ping Latency to Major Backbones:
4. Geekbench 6 CPU Benchmark
5. Complete YABS Combined Output
## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ##
Yet-Another-Bench-Script
v2026-10-07
https://github.com/masonr/yet-another-bench-script
## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ##
Basic System Information:
Uptime : 1 days, 18 hours, 20 minutes
Processor : AMD EPYC 7T83 64-Core Processor
CPU cores : 2 @ 2449.998 MHz
AES-NI : ✔ Enabled
VM-x/AMD-V : ✔ Enabled
RAM : 3.8 GiB
Swap : 1.5 GiB
Disk : 48.4 GiB
Distro : Ubuntu 26.04.1 LTS
Kernel : 7.0.0-38-generic
VM Type : KVM
IPv4/IPv6 : ✔ Online / ✔ Online
IPv6 Network Information:
ISP : Servitro LTD
ASN : AS213495 SERVITRO LTD
Host : Servitro LTD
Location : Frankfurt / London
Country : Germany / United Kingdom
fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/vda1):
iperf3 Network Speed Tests (IPv4):
Geekbench 6 Benchmark Test:
Test | Value
|
Single Core | 1128
Multi Core | 1946
Full Test | https://browser.geekbench.com/v6/cpu/19374765
Conclusion & My Experience
If you are looking for an ultra-cheap, highly connected VPS for:
1. Jump host / Bastion: SSH proxying, WireGuard/OpenVPN gateway, remote diagnostics.
2. Accessing other servers / VPSs securely: High speed, multi-gigabit pipes, and sub-millisecond backbone ping.
3. Lightweight administrative tasks: Cron jobs, status checks, backup triggers.
At $20/year (~$1.66/month) with 4GB RAM and 2 cores of AMD EPYC 7T83, Servitro is providing tremendous bang for the buck. The CPU steal is sitting firmly near zero, and network speeds exceed expectations.
Hello,
Refunds are not processed automatically. Simply create a support ticket, and we’ll process your refund.
Dear Users,
We understand the packet loss issues you’ve been experiencing over the past few days, and our entire team has been working continuously to resolve them.
We identified that the issue was caused by our new firewall. Our latest tests indicated that the problem had been resolved, and we are continuing to monitor the network to ensure stability.
We sincerely apologize for the inconvenience and appreciate your patience while we work to get everything back to normal.