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.
[BitsFlowCloud] Our First Offer! Starting at £8.4/Yr ! | US/DE/HK VPS & China Optimized VPS
This discussion has been closed.
Comments
For anyone who is wondering for making the switch to DE-NUE here is yabs
Hello,
If this incident did indeed occur, could you please submit the relevant evidence via a support ticket? This should include, but is not limited to:
1. Payment records;
2. The affected region;
3. Historical support ticket emails;
If you find the above steps too cumbersome, could you please provide your email address? I will search for all relevant records in both the current and previous billing systems.
If you believe I'm trying to downplay the impact of this matter, you are welcome to post the credentials in this thread.The entire matter should be made public, as the deletion without prior notice or warning within 24 hours of purchase constitutes a serious allegation against my business reputation. I will treat this with the same seriousness as a lawsuit and conduct a thorough investigation.
I can assure you that neither the previous team nor I personally could have done such a thing, as it is completely unreasonable.
If this incident occurred recently, the only case I recall involves a user who accidentally clicked the cancel button after purchasing a VPS and subsequently requested a refund (which I approved, as I support no-questions-asked refunds within 72 hours). What's baffling is that while submitting a support ticket, this user also filed a complaint with the payment gateway (per our Terms of Service, any complaint submitted to the payment gateway is equivalent to requesting the deletion of all your VPS instances and your current account). .
If you are a Japan user, please be patient—he'll be here soon
For example:
The application being used performs outbound scans via port 22 without the user's knowledge.
In the TOS, external scanning is strictly prohibited. Any violation will result in account suspension.
I use the same username on NodeSeek as well. You can verify it yourself.
I saw your historical posts on NS where you accused me of being an “unscrupulous merchant” and filed a complaint against the payment gateway.
It should be clarified that I explicitly stated in the Terms of Service (TOS) that outbound traffic on port 22 is blocked, and this restriction could not be lifted at the time of your purchase. Do you consider this complaint reasonable? Do you believe that simply because you didn't read the TOS when purchasing, you are exempt from adhering to it?
You feel wronged and have come to LET to “rub salt in the wound,” but have you considered whether your actions hold any merit?
Oh, and by the way, nearly all VPS providers will immediately terminate all services and close accounts when dealing with users who complain about payment channels, as this constitutes a complete breakdown in relations with the VPS provider. My approach is not an isolated case.
It’s all documented clearly on NodeSeek. While we were arguing about the necessity of port 22, you repeatedly blamed me for ‘not reading the TOS,’ and eventually kicked me out of the Telegram group. Only after that did I escalate the issue through the payment channel.
I’m not trying to add insult to injury — I’m warning potential customers to stay cautious. A vague excuse like ‘restructuring’ is impossible for outsiders to verify, and saying something like ‘I face the past directly’ doesn’t mean the same patterns won’t repeat.
Defending what happened in the past is pointless. Your real problem right now is restoring customer trust — that should be your number-one priority.
Your accusation against me is that “I deleted your service within 24 hours,” without mentioning any “violation of the TOS regarding payment gateway complaints.”
The blocking of outbound traffic on port 22 has been in place since I targeted the consumer market, not specifically aimed at you.
Just like in the community, many people don't understand why outbound traffic on port 22 is blocked and fail to grasp the potential risks it could pose to them.
The foundation of any VPS provider's service is its Terms of Service (TOS). If everyone assumes “not reading the TOS = no TOS = I don't need to follow the TOS,” it inevitably leads to chaos.
For example:
I previously violated Gorilla Server's TOS when they suspected order fraud. Though it led to a dispute, I accepted all consequences and sent an apology email—note that I'm not suggesting you should do the same. 99% of businesses will simply tell you “that's what the TOS says” when you raise an issue, assuming you read the entire TOS before purchasing. And let me clarify: you definitely saw that pop-up listing over a dozen terms and conditions when you bought the service, and you checked the box agreeing to them—otherwise, you couldn't have completed the purchase. Am I right?
I truly have no desire to defend past actions. If that were my mindset, I would never have created a Wall of Shame and permanently displayed it in the homepage footer for all to see. However, given your unfair accusations, I need to understand the details.
Is there a double-resource promotion for SJC 2026? I think I saw someone in a Telegram group mentioning they submitted a support ticket to apply for the "double" offer (though I'm not entirely sure if it was specifically for the SJC 2026 plan), and the staff said they would process it right away.
Dear Sir/Madam,
SJC does not apply to any double-up programs.
Transparency timeline of my order experience:
1) I purchased HK-2026-S (1GB RAM / 20GB Disk / 1Gbps / 1.5TB traffic) via the provider’s LowEndTalk promotional link.
2) The VPS was provisioned with 1024GB traffic allowance instead of the advertised 1.5TB.
3) I reported this in the LET thread. Provider replied they would check.
4) In private message, provider asked me to open a support ticket and said: "This is not intentional, and I appreciate your understanding."
5) After I opened the ticket, provider stated:
"There was no false advertising. You purchased the standard annual package, not the promotional annual package."
6) I decided not to argue further and requested a refund. Provider agreed and asked for my Alipay receiving code, which I provided.
7) Provider confirmed refund would be processed by Feb 4, stating outbound transfers were restricted and documents were submitted to Lift restrictions.
8) As of Feb 5 and Feb 6, no refund received and no further response from provider.
Just sharing the timeline for transparency so others can decide accordingly.
Hello,
Since you paid via Alipay, I need to process your refund through Alipay.
Currently, my Alipay account is frozen. I have announced in my notification channel that I will proceed with Plan B for refunds instead of waiting for Alipay to unfreeze the account.
This is not targeted at you personally, as this situation has indeed caused backlogs for at least 20 refunds involving Alipay payments.
Could you explain these potential risks please? Why would outgoing SSH be a potential risk?
If you're saying people are scanning other people's SSH, then that's already covered by your no scanning rule. But what do you have against SSH?
When I'm using a machine, I use outgoing SSH for: backups to my borg servers, access to my git repo, fetching web certificates from a centralised certbot, etc.
I've never encountered another provider that thinks outgoing SSH is dangerous, so please, if it's a potential risk, please explain why you think so...
Regarding outbound traffic on port 22, although I've addressed this before, I'm happy to reiterate:
The greatest risk isn't what you actively do, but what unknown “entities” are doing behind your back.
Previously, numerous malicious users purchased VPS servers and used port 22 for outbound scanning, triggering abuse reports against me.
Please note: Outbound traffic on port 22 is blocked by default, but this restriction can be lifted. If you choose to enable it and subsequently become unknowingly exploited by malicious applications conducting scans via port 22, penalties will be enforced according to our Terms of Service (TOS).
Outbound traffic on port 22 does not affect your use of SSH.
So, it's because MJJ are doing something they're specifically told not to. Then they overreact and start attacking you when you canceled and banned them from your system, right?
I don't think this has anything to do with MJJ; you're making a sweeping generalization.
This kind of thing doesn't just happen to malicious users—legitimate users sometimes encounter it too. For instance, the proxy panel they use might have been tampered with, or sometimes Cloudflare even flags their VPS as “preferred,” exhausting all their traffic within a single day.
Additionally, an explanation:
I never believed that “they did something they shouldn't have, causing me to overreact.” On the contrary, the reality is that “my former partners and I (I attribute this to myself because I don't wish to deny any actions that occurred, even if they were decisions made by previous team members) did something we shouldn't have, causing them to overreact.” It sounds a bit convoluted, but I hope you understand what I'm trying to convey.
You can find the answer to this point by looking for the “Wall of Shame” in the footer of my official website. If I truly believed “I was right and others were wrong,” I wouldn't have built “this wall” and made it public at all
oneman mjj,cautious
Which unknown entities are these?
Which is already against your TOS.
Ummm, yes if you blocked it, it would most certainly affect my use of SSH.
Outbound port 22 blocking is enabled by default to reduce potential misuse beyond your control (specifically external scanning using port 22).
If this causes issues, you may request an exemption—this policy isn't set in stone
I'm not sure if this is a language barrier or if you just don't know what you're talking about.
If outbound port 22 is used for scanning, that is not "potential misuse beyond your control". It would be entirely within the control of whoever had the VPS. And it is already covered by your TOS, so blocking that port isn't helping you, except for the cases where people just ignore your TOS and scan anyway from your VPS.
If you are actually talking about "beyond your control", then that would be inbound port 22. And that's needed as well to be able to log onto the machine.
I believe the merchant's intention is to block port 22 by default, but exemptions can be requested via a support ticket. Users will be held responsible for any consequences.
It's actually very simple:
All you need to do is search: What security risks does opening port 22 for outbound traffic pose?
How about you tell us?
Any search results about security risks for out going connections might make sense from within a corporate firewall, but not for a VPS.
But anyway, I think I've learned enough that I don't want one of your VPS, so no point continuing this further.
Yes, I know he said that, but he hasn't explained why he thinks port 22 is so very dangerous and puts you at risk from "external entities" (his phrase). There are no consequences of allowing outgoing connections on port 22, except allowing users to SSH to other machines.
Unless he means he's trying to stop people using his VPS to scan port 22 on other machines, in which case there's still no point blocking it, because he's already got a rule in the TOS which can allow him to terminate a customer who abuses it.
There's literally no reason to make customers who want to make outgoing SSH connections have to perform like circus clowns and beg him via ticket to unblock port 22. Blocking it doesn't protect anyone.
Your remarks are clearly extreme. What gives you the right to assume that users requesting to lift restrictions on outbound traffic through port 22 are clowns?
Is that how you define other users?
Is “just because you haven't seen it doesn't mean it shouldn't exist” the logic you deem reasonable?
Whether you use my service or not is irrelevant, but I cannot agree with your sweeping generalizations.
I have no desire to engage in an argument with you, and I believe we won't come to blows.
Generalization doesn't happen without patterns. Bad apple spoils the batch.
Anyway, CF also generalized your IP range because of the past behaviors. Burning 500-1000GB is quite crazy.
Let's do the math.
It's not surprising your IP blocks got bad rep. It's puzzling how the customer could use the server, write some program, yet execute it without doing testing, let alone putting exponential back off or scheduled sleep.
Sorry, I assumed it's something like this.
1. Customer do something bad
2. You (or your previous team) stopped the instance or cancel it without refund (severe violation of ToS with consequences to business)
3. The customer start badmouthing you
But, you're honest it was caused by problems on your side which customer react negatively.
You are absolutely right. While these incidents occurred in the past, now that I have personally taken charge, I can assure you they will not happen again.
As a service provider, mistakes are inevitable. However, I have rarely seen a business openly summarize all their past faults for customers to review. Please understand that this isn’t a PR stunt; it is a genuine reminder to myself of how I need to operate from now on.
I take full responsibility for all past errors—that is beyond question.
Regarding the blocking of outbound traffic on port 22: You might feel this restriction implies we view users as 'bad actors.' However, you may not be aware of a specific incident where dozens of users—all running the same proxy panel software—unknowingly had their servers hijacked by malicious code to scan others via outbound port 22. This resulted in me receiving over 20 abuse reports in a single day, which forced me to implement this default blocking rule.
However, I would like to clarify a few things:
The block can be lifted. However, once lifted, you bear full responsibility if the port is used maliciously.
Blocking outbound port 22 does not break SSH access. Your incoming SSH connection works perfectly fine. This primarily affects actions like using git or using this VPS as a jump host to SSH into other servers. A simple workaround is to change your SSH port to a non-standard port and run systemctl restart ssh, which bypasses the rule. Alternatively, you can simply open a ticket to request unblocking. It’s not a hassle—I approve all requests and remove the rule for verified users.
If anything remains unclear, please feel free to ask, and I will be happy to explain further.
Hello there,
Just wanted to share a quick experience with BITSFLOW.
I bought US-FRM-2026 package, price is cheap, payment went through smoothly, and my account was activated instantly after paying. No delays at all.
Server deployment was crazy fast too, the VPS deployment was ready in seconds.
The best part for me is the Rescue Session feature. I messed up my SSH config and locked myself out (my mistake), but the rescue mode gave me root access so i could fix everything. That feature alone saved my server.
For a low-cost VPS: fast setup, smooth process, and a solid safety net. Pretty happy so far.
It's pretty good.
YABS of the HK node:
Is Windows available??