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.
Hi @lvqiuzilu, I think the point our team tried to explain in the ticket got lost in translation too. We haven’t identified a fault with Twelve99 or our network. The 8–23% figures you cite are from intermediate MTR hops, where carrier routers can deprioritize ICMP replies (also known as ICMP deprioritization which, by the way, is very common by Tier 1’s). Loss shown on such hops doesn’t necessarily mean traffic is being lost on its way to the VPS, or our network. The ping.pe tests show the VPS responding without loss from the locations tested.
With regards to your connectivity from China, there are a lot of external factors involved (such as government intervention by China, GFW, etc), all of which can affect latency and packet loss, so that’s why we offered to try another datacenter location in the ticket, and that offer remains open.
It's not a "recourse", it's feedback. If it's a "recourse", then the only reason you're telling them is to exert pressure unless they obey you. That's a threat.
@dustinc Fair point on intermediate hops — ICMP deprioritization on Tier 1 routers is real, and hop-by-hop MTR loss doesn’t always equal end-to-end loss.
But the 12% figure was at the endpoint itself — the final hop, measured over a sustained WinMTR run. That’s end-to-end loss by definition, not an ICMP artifact. Same story for the ~95% loss on the telecom path, and your own team’s test averaging ~290ms.
None of that is about blame — it’s about what happens when the service doesn’t work for the buyer.
@forest A threat aims to change a decision. The refund refusal was already declared final before I mentioned the timeline — there’s nothing left to pressure. That’s the difference between notice and a threat. By your definition every review ever posted here would be a threat, since all reviews exert some pressure.
@lvqiuzilu Just out of wondering. What was your method of payment for the service?
I find this whole "too early in China, test in 5 hours" issue interesting. That seems to imply that connectivity is good off-peak and potentially poor during peak times.
How is this an issue for RackNerd when RackNerd's performance is generally solid domestically in the United States?
Wouldn't that point to potential connectivity issues within or approaching China, and not with RackNerd? I live in the Southeast of the United States, and my RackNerd VPS in New York gets solid connectivity 24/7/365. Hiccups now and then? Sure. But overall, it's reliable with no noticeable "peak" or "off-peak" performance differences.
What am I missing?
Your use case is YOUR problem, not theirs.
It's well documented they don't do refunds. If you need to assess performance before making an annual purchase, pick a provider that advertises a refund period. Duh.
You don't appear to understand what ICMP is otherwise you wouldn't have replied like that telling us that. You don't have any data from your "use case" showing packet loss or impairment. Only ICMP test results.
You're a nuisance.
I think you should test the IPs they provide first before deciding to buy. Have you done any testing on them yet?
Hi @jbarr -- To be transparent, you're not missing much here
This is very much just something unique to how China works, and it applies to every VPS provider, not just us.
We sincerely appreciate you sharing your experience with your New York VPS, and we're happy to hear it continues to serve you well! As you mentioned, our services are reliable and quite performant. We've worked hard to build a business that customers can count on for their production workloads, and we wouldn't be where we are today without earning that trust. Our consecutive years on the Inc. 5000 reflect actual verified revenue growth, and behind that growth are customers choosing to deploy with us, stay with us, and grow with us.
Regarding China, its just a very dynamic, constantly evolving, and interesting subject overall. Connectivity from China to US networks, comes with its own challenges, and most of them are outside of any provider's control. A VPS can deliver consistently solid performance for one part of China, while someone connecting from another part in China experiences congestion along a different network path during different hours, etc. International capacity, carrier routing, and GFW filtering can all affect that experience. As mentioned, this is something users can encounter with any VPS provider (so it isn't something isolated to just RackNerd)
As I mentioned earlier, I've personally been in this industry for over 18 years, and have seen it all, you name it. For example, PCCW was considered a highly desirable bandwidth carrier for Los Angeles providers serving customers in China. Over time, those preferences and results have changed. What works well for one Chinese carrier or province may perform quite differently for another, and what works well today can change down the road. China is a very large country, so there really isn't one experience that represents everyone there. We've found that our current network blend in LA of Cogent, Arelion, and Crown Castle/Lumen does work quite well, for the vast majority of our customers, and provides a very decent network blend.
We also have a large number of happy customers in China enjoying our services, including at our West Coast locations. Los Angeles is a popular choice for that audience. At the same time, no provider can promise that every route into China will remain perfect at every hour for reasons explained earlier.
We absolutely want customers to have a good experience, wherever they're connecting from. We have multiple datacenter location options for customers to choose from too, which helps
Your experience is what we work to deliver every day, and we appreciate you trusting RackNerd with your business! 👊
It is not their fault for the connectivity to China. In fact, for any packet loss at an end point they cannot control. No host can buy more BW for your ISP at home so there is no saturation at peak hours. That is your home ISP's fault, it is like faulting the host for a construction worker next street who nicked your fiber.
You can and you should test connectivity before purchase. The internet is increasingly fragmented and there can be no guarantees even with Tier 1 transit that it would be always at the same latency, for example, all over the world. In China's case that is much-much worse than in other places on top of that.
Regarding refund, that costs money. The host COULD offer you one. They are only obligated if you have something like 14 days money back guarantee or similar like in the EU. If they decide, like in this case, that it is not their fault and refuse a refund as per their ToS, then that is about it, you have been helped with tools and knowledge here to avoid it in the future, consider it the cost of the tuition.
I think the attitude was professional and the handling timely. I heard bad things about them, but this is a big plus.