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.
RackNerd refused refund for VPS with 12% endpoint packet loss — full timeline
Hi all, sharing my experience with RackNerd in case it helps others decide. Keeping it factual with a full timeline.
The service: VPS 23.94.208.129 (Los Angeles). Ticket #SQ98186 with their Billing department.
The problem (all documented):
- From my home connection: ~12% packet loss at the endpoint itself, avg 159ms (WinMTR)
- Inside the US, Twelve99 backbone: 8%–23% packet loss on intermediate hops
- China Telecom path: ~95% packet loss
- Return path detours via Europe: 214–267ms
- RackNerd's own test from the VPS averaged ~290ms
- Full test report: https://Report.Check.Place/net/1WYHF63AA.svg
Timeline:
- Opened ticket #SQ98186 asking for a refund — full, or pro-rated, to the original payment method.
- Support (Dejana P., Dillon S.) asked for MTR results a couple of times; I pointed to the report and findings already in the thread each time.
- Sep 28 ~09:18 PDT: Anthony Fye (Customer Success Manager) gave a final written decision — refused both full and pro-rated refunds to the original payment method, called it final. Offered $18.30 account credit or a migration to a different location/IP instead. I declined the credit (original payment method only, no account credit).
- Sep 28 11:16: I posted a detailed 7-point rebuttal (the endpoint's own 12% loss, Twelve99 backbone loss, their own 290ms test result, and contradictions in their reasoning).
- Sep 28 ~13:57 PDT: Anthony replied again — redefined the credit/migration as pure "courtesy", attributed the issue to Chinese carriers / GFW / congestion, restated the refusal.
My take: a VPS with 12% packet loss at its own endpoint is not a usable service, no matter where the loss is attributed. "Online" is not the same as "usable". I'll let the community judge whether the refund refusal was reasonable.
Has anyone else had a similar refund experience with RackNerd?
Thanked by 1WyvernCo
Comments
@dustinc
Foreign (non-Chinese) networks cannot guarantee 0% packet loss to mainland China past the GFW. Your best option is to test companies network by using the test IP during peak times of the day to check loss before ordering.
@MikeA Fair point on testing first — lesson learned, point taken.
One clarification: I never asked for 0% loss. 12% loss at the endpoint itself, 8–23% inside the US on Twelve99, ~95% on the telecom path — that's not imperfect cross-border routing, that's an unusable box. This thread is about the refund side of it: refusing even a pro-rated refund to the original payment method for a service in that state.
To be honest, I don't see any loss to the IP provided right now.
https://s.ping.pe/J/W/snap_JWbuLLqA.html
Too early in China. Test in 5 hours.
I always ask for at least 20% loss
So, it just dropped the packet when busy / overloaded ? Noted.
Yea good ol international China connectivity. At least with Russia there is no packet loss, just straight network blocks!
Edit - 10 AM to 3 PM I think is where I've seen most packet loss at in the past, and that comes with latency increase due to the congestion.
@oloke Appreciate you testing it. A single snapshot at 7am Beijing time is off-peak though — MikeA's right that timing matters here. The 12% wasn't from one ping; it was sustained WinMTR from my home connection, plus 8–23% loss inside the US on Twelve99 (nothing to do with China peak hours), and RackNerd's own test averaging ~290ms. If you re-run during 8–11pm Beijing time I'd be curious how it compares.
@tenji That's exactly it — and that's my whole point. Usability that depends on the hour, sold with no such caveat, and then no refund (not even pro-rated) when it's unusable during the hours you actually need it.
@MikeA Thanks — 10am–3pm lines up with what I've observed as well. Useful reference.
Hi @lvqiuzilu -- I reviewed your ticket, and we aren't seeing a service issue with your VPS or our network. The ping.pe results @oloke shared also show the VPS responding without any packet loss. I just ran one as well, and took a screenshot for you: https://i.ping.pe/4/u/img_4ummNahN.png
Our team spent quite a bit of time reviewing your reports. We offered account credit and even a migration to another node or location to see if a different route would work better from where you are in China. We sincerely wanted to help. At the same time, it's a two way street -- when the options we offer are dismissed and/or derailed by you with threats, it becomes difficult to make progress toward a resolution.
I also saw our offers to help in the ticket (e.g. migrating to a different location, or an account credit refund), were characterized by you in the ticket as an “admission of fault.” Whether that was your intent or simply how the LLM you're using phrased it, that isn't what those resolution paths meant. They were our team going the extra mile to help with connectivity that can vary considerably, given the nature of China.
You then wrote back in the ticket when we attempted to further help, “This is not a threat — it is notice of the next steps I am taking.” You're welcome to share your experience publicly, and we're happy to share our side too. But I don't think it's fair to say we refused to help because we couldn't agree to a refund to the original payment method, as we sincerely spent lots of engineering time on your ticket, as well as explaining this to you as well as the resolution paths we can offer.
Taking care of our customers is how we've built our reputation and we intend to continue to do so. If you'd like to pursue the migration or another option our team offered, we're still happy to help.
A review or post on LET doesn't alter our original stance, so please review the ticket and consider our original offers, as we're ultimately interested in helping. We also offer test IPs and a looking glass so customers can check routes before ordering, as we have quite a bit of datacenter locations to choose from. One location may work better than another, depending on the part of China you are from. We have many happy customers in China, too, but testing is especially important for that region. Routes and performance can change with congestion and GFW intervention. I've personally been in the hosting industry for over 18 years, and if there's one thing I've learned, it's that the “perfect” network to China never stays perfect for long. Routes on the China side change, and government/GFW intervention can affect connectivity. No provider can promise a perfect route into China at every hour, forever.
I think there's a site where you can test using this
https://www.itdog.cn/ping/
not valid and not their fault
Hi @dustinc, appreciate you coming here to respond. A few points:
On the "no packet loss" tests: @oloke's ping.pe and yours were run in the morning Beijing time — off-peak. @MikeA already noted "too early in China, test in 5 hours." A single off-peak snapshot doesn’t erase sustained WinMTR showing 12% loss at the endpoint itself. And the 8–23% loss on Twelve99 was inside the US — that has nothing to do with China peak hours or the GFW. Your own team’s test averaged ~290ms.
On "threats": telling a company "I will share my experience publicly" is not a threat — it’s the most ordinary consumer recourse there is. I’m sharing facts and a timeline, which is exactly what this Reviews section is for.
On engineering time: I don’t doubt your team spent time on the ticket. But time spent isn’t a resolution. The outcome on record is: documented 12% endpoint packet loss, and no refund to the original payment method — not even pro-rated.
On test IPs: fair point for future purchases, and I’ll use them. It doesn’t change this case.
Understood that the post doesn’t change your stance — it was written as a factual record for other buyers, not as leverage. As said in the ticket, if management ever reconsiders a refund to the original payment method, I’m still open to resolving this.
@aphex 'Not their fault' is exactly my point too — I’m not asking anyone to take blame. The question is simpler: when the service doesn’t work for your use case, do you keep paying for it, or do you get your money back?
@bbmmsvr4u Thanks — itdog is a handy one, I’ll use it for future tests.