VSM: Compress sing-box setup, management, and delivery into one command

The original goal of VSM was simple: after buying a VPS, users should not have to install sing-box manually, write JSON configs, configure systemd, and copy share links by hand.

That workflow has now moved further. VSM is still installed with one command, but after installation it gives you more than a local menu. It also exposes a VSM console entry that can be opened in the browser. From https://nodebuf.com/vsm, you can connect to your own VPS, create nodes, edit profiles, inspect runtime status, run unlock checks, set traffic limits, and even use one VPS as a relay entry to another upstream node.

The boundary matters: nodebuf.com/vsm is only a browser-side management UI. The VSM URL, username, password, and node operation requests are not submitted to the nodebuf.com backend. The browser talks directly to the VPS where VSM is installed.

One-line installation

Run this on the VPS:

curl -fsSL https://nodebuf.com/install-vsm.sh | sudo bash

After installation, the terminal still prints the important access details:

• the public HTTP URL of the VSM API
• the Cloudflare Quick Tunnel HTTPS URL
• the random access path
• username and password
• a quick-connect link such as https://nodebuf.com/vsm?code=...

To reopen the local menu later, run:

vsm

If the Cloudflare Quick Tunnel expires, SSH into the VPS and run:

vsm cf restart

You can also use vsm cf start, vsm cf stop, and vsm cf status to manage that temporary HTTPS entry separately.

VSM now has two layers

The more accurate model is:

• VPS side: vsm installs sing-box, generates configs, starts the API, maintains the Cloudflare entry, and stores local state.
• Browser side: https://nodebuf.com/vsm provides the graphical console, but it only connects directly to your own VPS.

This keeps the site from becoming a centralized control plane for user servers. After the user enters the access URL, username, and password, the browser sends requests directly to that VPS.

If “remember me” is enabled, the connection details are stored only in the current browser localStorage. If it is disabled, a successful login will not keep those credentials.

The current /vsm entry page first explains what VSM is, links to this article on the right, and then asks for the access URL, username, and password printed by the installer.

After connection, the dashboard shows the sing-box state, script version, profile count, node list, HTTP / Cloudflare entrypoints, and runtime actions.

Node management is now more than adding one protocol

The “Profiles” page in the VSM console can create, edit, and delete nodes, and it displays existing nodes in a table. Each row has an action menu for copying the share link, editing, deleting, and converting the node into common client formats.

The currently practical delivery targets include:

• VLESS REALITY
• VLESS HTTP/2 REALITY
• VLESS / VMess / Trojan over WS, H2, and HTTPUpgrade with TLS
• Hysteria2
• TUIC
• Shadowsocks
• AnyTLS
• Socks

The form is also more user-oriented now:

• node names default to a v2rayse prefix
• the server address defaults to the VPS public IP
• ports default to random available values instead of always using 443
• UUID, password, Reality keys, and short IDs are filled automatically where possible
• protocols that require a domain are grouped separately from protocols that can use an IP directly
• optional fields are moved into advanced settings
• two nodes cannot use the same port; saving will fail with a clear error

The goal is not to expose every sing-box option at once. The first goal is to generate a working node reliably.

Traffic limits: monthly or daily blocking per node

VSM can now set traffic limits per node. For example, a VLESS REALITY node can be limited to 200 GB per month, or switched to a daily limit.

This is not just a number shown in the UI. On the VPS, VSM uses nftables to count traffic by node port and blocks that node port once the limit is reached. Because different nodes use different ports, VLESS, VMess, Trojan, and other nodes do not affect each other.

One detail is important: if a user sets a traffic limit but the VPS does not have nft / nftables, VSM refuses to save the limited node and explains why. That prevents a dangerous situation where the UI says “20 GB” but the system has no actual enforcement and the VPS traffic gets drained.

Monthly limits reset next month. Daily limits reset the next day.

Unlock checks run from the VPS egress

The VSM console also includes an “Unlock Check” menu for checking whether the current VPS egress IP can access common streaming and AI services.

These checks do not go through the nodebuf.com backend either. The browser triggers the check and reads the result, but the actual requests are sent from the connected VSM VPS. That makes the result reflect the real egress ability of that server.

Relay nodes: use a Hong Kong entry for a US upstream

Another new capability is relay nodes.

Suppose you have a Hong Kong VPS with better entry latency, and another US server that is slower to reach directly. You can create a local entry node on the Hong Kong VSM server and route that node’s traffic to the US upstream node.

The user connects to the Hong Kong IP and port, while the final egress IP becomes the US upstream node.

This is useful when you want to:

• improve entry connectivity with a nearby VPS
• wrap a remote upstream node behind a better local entry
• test a separated entry-and-egress chain

The upstream can be pasted as a vless://, vmess://, trojan://, or ss:// share link, or as a sing-box outbound JSON object.

Share links can continue into conversion

After a node is created, the VSM console can copy the share link directly or convert the current node into common client formats:

• sing-box
• Mihomo
• Clash
• Base64
• Surge
• Quantumult X
• Surfboard

This connects server-side deployment with client-side delivery. Users no longer need to manually reorganize parameters between an install script and a converter page.

Recommended workflow

For a first run, use this order:

1. Run the one-line install command on the VPS.
2. Copy the https://nodebuf.com/vsm?code=... quick-connect link printed by the terminal.
3. Open the VSM console in the browser and confirm the connection.
4. Create a VLESS REALITY node or another protocol that fits the environment.
5. If the node will be given to someone else, decide whether it needs a daily or monthly traffic limit.
6. Copy the share link, or convert it into sing-box, Mihomo, Clash, or another client format.
7. Use “Unlock Check” if you need to verify egress access.
8. Create a relay node if you need entry acceleration or cross-region forwarding.

Who it is for

The current VSM is especially useful for:

• users who can buy a VPS but do not want to deploy sing-box from scratch every time
• users who want server-side control with browser-based management
• users who need to give nodes to others with daily or monthly traffic limits
• users who want to check streaming or AI service availability from a VPS
• operators with multiple VPS servers who want relay chains such as Hong Kong to US or Japan to US
• site owners writing tutorials, VPS recommendations, or affiliate content who want to reduce support overhead

Summary

VSM now solves more than “how to install sing-box”.

It is closer to a complete self-hosted node workflow:

• one command installs sing-box and VSM
• the local vsm command handles maintenance
• the /vsm console provides browser direct-connect management
• profile forms generate and validate configs
• traffic limits prevent overuse
• unlock checks confirm real egress ability
• relay nodes separate entry from egress
• conversion output delivers the server-side node to client formats

For self-hosted node users, this is more complete than only providing an install command, and it starts earlier than a pure node converter. It puts VPS installation, node maintenance, traffic control, egress checks, and client delivery into one repeatable flow.