All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
becarefull of the bytevirt
Robin D
2026/10/18 (11:12)
Operator
Alright, best to just stay away.
yu lesshui
2026/10/18 (11:08)
Owner
It’s so obvious—the IP must have been swapped. Everything was fine before you updated the system. You perform a system update, reboot, and then claim the IP is blocked by the Great Firewall? Who’s going to believe that?
Well, those who know, know.
You’re a businessman, after all.
Just steer clear.
Robin D
2026/10/18 (10:51)
Operator
The IP hasn’t been changed; it’s blocked by default. If it happens not to be blocked, consider that an act of mercy from the Great Firewall—an unexpected exception.
yu lesshui
2026/10/18 (10:50)
Owner
The IP was working fine before—how did it suddenly become one that’s blocked by the Great Firewall?
Does a system upgrade really change the IP address?
Robin D
2026/10/18 (10:21)
Operator
It’s linked; the NAT IPv4 is blocked by default.
yu lesshui
2026/10/18 (10:20)
Owner
Hello. Regarding the external domain name for the server I purchased—natsg4.bytevirt.net—has the association not been set up yet?
I’m currently unable to log in via remote connection.
====this is the email ======================================
ByteVirt LLC
Dear Customer,
We are writing to inform you of an emergency security maintenance affecting the host node of your service(s).
Event: Emergency Security Maintenance (Host System Upgrade and Kernel Update)
Affected Service(s): 7c1d95da1d.bytevirt.com
Start: 2026-10-17 05:30 (UTC)
End: 2026-10-17 08:30 (UTC)
Expected downtime per VM: approx. 30–75 minutes within the window
Why this maintenance cannot be postponed
This week, a critical Linux kernel vulnerability ("PwnEscape", tracked as CVE-2026-99999, rated 9.3/10) was publicly disclosed. It is located in the host's networking stack: a malicious virtual machine on the same physical host can abuse it to read the host's memory, and in the researchers' lab demonstration, to take full control of the host.
If left unpatched, another tenant on the same host could potentially access data belonging to your VM. No configuration inside your VM can protect against this. The only effective fix is to update the host system and kernel and reboot the host. Because the patched kernel is only available for the newer version of our virtualization platform, this host will also be upgraded, which takes longer than a simple reboot.
What will happen
Your VM will be shut down gracefully, the host will be upgraded and rebooted into the patched kernel, and your VM will be started again automatically if it was running before the maintenance.
Your data, IP addresses and configuration will not change.
If you run a customized system, it may fail to boot correctly and require manual intervention via the VNC console, or a reinstall/reset from the control panel.
What we recommend
Make sure important services are configured to start automatically on boot.
Take a backup or snapshot of critical data before the window.
If your VM does not come back online within 30 minutes after the window ends, please open a support ticket and include your service IP.
We apologize for the short notice and thank you for your understanding.
visit our website | log in to your account | get support
Copyright © ByteVirt LLC, All rights reserved.
Comments
If your IP is blocked by the GFW it is beyond providers control.
A node reboot doesn't change your IP, you are making things up.
I don't see any scam
You should complain to the great firewall, why don't you?!
Why do MJJ like to vent about an IDC provider—which caters to Chinese users—on a forum based outside of China?
How do OP dont know if IP changed ? SSH via Domain ?
If the problem persist, leave your country and try again
root@7c1d95da1d:/# history
1 ip a
2 bash <(wget -qO- https://raw.githubusercontent.com/fscarmen/sing-box/main/sing-box.sh) --LANGUAGE c --CHOOSE_PROTOCOLS a --START_PORT 45302 --PORT_NGINX 45303 --SERVER_IP 188.2xx.xx.xx --CDN dash.cloudflare.com --VMESS_HOST_DOMAIN sg.xxxxx.xyz --VLESS_HOST_DOMAIN sg.xxxxxxx.xyz --UUID_CONFIRM xxxxxxxx --PORT_HOPPING_RANGE xxxx:xxxxxx --NODE_NAME_CONFIRM bucket
3 sb
4 ss -tanl
Upon reviewing the history of the linux, I realized the error was on my end, not the carrier's.
Next time, get claude/ChatGPT/kimi to recheck
You must be running a faulty firewall, why don't you turn it off and see if the problem gets fixed?