spiritLHLS/ecs: the shell VPS benchmark script that now points at its own Go replacement
VPS 融合怪服务器测评脚本 —— 更推荐使用无环境依赖的 Go 版本:https://github.com/oneclickvirt/ecs VPS Fusion Monster Server Test Script — we now recommend the Go version (zero external dependencies): https://github.com/oneclickvirt/ecs
At a glance
- What is it?
- spiritLHLS/ecs is a Shell script that bundles system info, CPU, disk IO, network speed, streaming and IP quality tests into one VPS benchmark run. The README now tells new users to use the Go rewrite instead, which changes who should still pick this version.
- Who is it for?
- Adopt spiritLHLS/ecs only if you are on a system or architecture the Go version does not cover, or if you specifically want the mature Shell parameter set (for example -m, -ctype gb5, -dtype fio, -mdisk, -stype). Do not adopt it if you need non-root testing, minimal changes to the host, or new features: the README states the Shell version gets maintenance only and that feature work moved to the Go rewrite.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 12 days ago.
- What is it written in?
- Mainly Shell, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What spiritLHLS/ecs collects in a single run
A VPS buyer usually has to run four or five separate benchmark scripts to get a picture of a machine: one for basic system info, one for CPU, one for disk, one for network, one for streaming unlock. spiritLHLS/ecs merges those into one Shell script with a menu. According to the README, the run covers basic system information, CPU scoring, disk IO, three-network speed tests, return-route tracing, streaming media checks, TikTok checks and IP quality detection.
The intended audience is people evaluating a VPS before or after purchase, not people benchmarking production servers. The README says the project should be run from /root to avoid environment dependency problems and explicitly warns against using it in a production environment. It also says results are written to test_result.txt in the current directory, which is the practical reason to run it inside screen or tmux: a long test over an unstable SSH connection can otherwise be cut off.
The README also lists a separate IP quality check with 15 database queries, DNS blacklist lookups, IPv4 and IPv6 checks, ASN and address lookups, and mail port detection. That one is a distinct command rather than part of the main menu flow.
How the Shell version is put together
The repository is mostly one large entry point, ecs.sh, plus ipcheck.sh and a handful of helper scripts (customizeqzcheck.sh, back/, archive/, lowpage/). The README is candid about provenance: it states that apart from marked original content, other sections are adapted and modified versions of existing scripts, and that they differ from the originals. CPU scoring defaults to sysbench, not Geekbench, though -ctype lets you pick gb4, gb5 or gb6. Disk IO combines a dd test taken from lemonbench and an fio test taken from yabs, with the README noting dd is faster but less accurate and fio is slower but constrained by disk and memory size.
The README claims parallel execution is used in some stages and that this saves two to three minutes versus sequential execution. That is the project's own statement, not an independently measured figure.
The IP quality section is described as original work, and the README notes the version inside the main script is simplified: it does not query Cloudflare threat scores, while the standalone IP quality command is the full version. That distinction matters if IP reputation is the reason you are running the script at all.
Installing and running spiritLHLS/ecs for the first time
There is no package to install. The README gives several one-line download-and-run forms; the GitHub one is the most direct. The command downloads ecs.sh, makes it executable and starts it interactively:
curl -L https://github.com/spiritLHLS/ecs/raw/main/ecs.sh -o ecs.sh && chmod +x ecs.sh && bash ecs.shAfter this you get the menu. For an unattended run, the README shows the same download followed by a parameter flag. The example below selects menu option 1, which the README describes as the full fusion test:
curl -L https://github.com/spiritLHLS/ecs/raw/main/ecs.sh -o ecs.sh && chmod +x ecs.sh && bash ecs.sh -m 1The README states that -m supports up to three levels, so bash ecs.sh -m 5 1 1 picks the first sub-option under the first sub-option of main menu item 5. Other documented flags include -en for English output, -bansp to skip the speed test, -banup to skip share-link generation, and -r b to test the Beijing return route.
To run only the basic system information instead of the full suite:
bash ecs.sh -baseThe README says results land in test_result.txt in the current directory. The full and lite versions upload results to pastebin and return a share link unless you pass -banup. The standalone IP quality check has its own command:
bash <(wget -qO- bash.spiritlhl.net/ecs-ipcheck)Expect the full run to take a long time on weak hardware. The README links an example of a very poor machine that took 47 minutes to complete.
The Go rewrite is the real recommendation, and the README says so
The most important thing about this repository is in its own preface. The README states that the Shell version will no longer receive new feature development and is maintained only, and that the tests have been fully rewritten in Go at oneclickvirt/ecs. It lists the reasons: testing on systems and architectures this project does not cover, bugs or dependency errors the Shell version cannot get past, avoiding changes to the host configuration, running without sudo or root, and faster or more comprehensive tests.
It also notes the Go version needs no third-party shell file references and supports non-root testing. Those are not cosmetic differences. A Shell benchmark that installs packages and rewrites host state is a different tool from a static Go binary you can run as an unprivileged user. If any of the four conditions above describe you, this repository is the wrong choice and the README is telling you that directly.
The sponsorship note adds a boundary worth reading carefully: sponsors fund this repository only, and the README states they are unrelated to the separate Go version project.
Where spiritLHLS/ecs breaks or does not fit
The README states plainly that the project updates the package manager by default and should not be used in a production environment. That is a real constraint, not a disclaimer. On a live server, an automatic package manager refresh can pull in changes you did not plan for.
Coverage is uneven. Fully supported systems are Ubuntu 18+, Debian 8+, Centos 7+, Fedora 33+, Almalinux 8.5+, OracleLinux 8+, RockyLinux 8+, AstraLinux CE and Arch. FreeBSD is only half-supported and requires pkg install -y curl bash first; Armbian is also half-supported. If you are on a distribution outside that list, the README sends you to the Go version rather than promising the Shell script will work.
Network access is mandatory. The README says any location works as long as it can reach the internet, and that a machine with no public network cannot be tested. The README also warns that although the project uses CDNs for domestic and international acceleration, loading inside mainland China can still be slow because of CDN connectivity or bandwidth limits.
Finally, the IP quality check embedded in the main script is the simplified one. If you need Cloudflare threat scoring, you have to run the standalone IP quality command instead.
Alternatives and how they differ in approach
The README itself points to oneclickvirt/ecs, the Go rewrite, as the preferred path. The difference is structural: it is compiled, has no third-party shell file references, and per the README can run without root and with minimal environment changes. The Shell version instead assembles third-party scripts, some adapted from bench.sh, superbench.sh, yabs and lemonbench, and executes them in place.
The README also mentions a third-party scripts section that collects scripts of the same type from other authors, for cases where the fusion script does not satisfy you or produces an error. That is a useful escape hatch, and it is honest about the fact that no single benchmark script covers every case.
A narrower option is to run the individual upstream tools directly: yabs for fio disk and Geekbench, lemonbench for dd disk and CPU, bench.sh for basic information. You lose the single menu and the combined result file, but you gain a smaller blast radius on the host and you know exactly which version you ran. That trade-off is the honest reason to skip this project even when it would technically work.
Maintenance, licence and upgrade cost
The repository is not archived, and the last push was on 2026-09-04. The README describes the Shell version as maintenance-only, with new feature work moved to the Go rewrite, so upgrades here should be expected to be dependency and component bumps rather than new test categories. The changelog entry from 2026.08.27 is exactly that kind of change: it upgrades the speedtest-go download to v1.8.3.
There are no retrieved releases, so the practical upgrade path is re-downloading ecs.sh from the URL in the README rather than tracking versioned artifacts. Because the script installs dependencies on the host, an upgrade is not a drop-in binary swap; it can change what gets installed. That is another argument for running it in a disposable environment.
The licence is MIT. That is permissive and places few obligations on how you reuse or redistribute the script, but the README notes that parts of the script are adapted from other projects, so if you plan to redistribute a modified version, check the upstream terms of the components you keep. This is a description of the licence situation, not legal advice.
Editorial conclusion
Adopt spiritLHLS/ecs only if you are on a system or architecture the Go version does not cover, or if you specifically want the mature Shell parameter set (for example -m, -ctype gb5, -dtype fio, -mdisk, -stype). Do not adopt it if you need non-root testing, minimal changes to the host, or new features: the README states the Shell version gets maintenance only and that feature work moved to the Go rewrite. Before running it, verify that your distribution is on the fully supported list, that you are comfortable with the script updating the package manager on the host, and that you have a screen or tmux session ready, because the README notes a badly configured machine once took 47 minutes to finish.
Frequently asked questions
What does the spiritLHLS/ecs script actually test?
According to the README it combines basic system information, CPU scoring, disk IO, three-network speed tests, return-route tracing, streaming media checks, TikTok checks and IP quality detection into one run. A separate command handles the fuller IP quality check with 15 database queries and DNS blacklist lookups.
Should I use spiritLHLS/ecs or the Go version?
The README recommends the Go version at oneclickvirt/ecs and lists the cases where you should switch: systems or architectures this project does not cover, dependency errors, wanting to avoid changing host configuration, wanting to test without sudo or root, or wanting faster and more complete tests. The Shell version is described as maintenance-only.
Which operating systems does spiritLHLS/ecs fully support?
The README lists Ubuntu 18+, Debian 8+, Centos 7+, Fedora 33+, Almalinux 8.5+, OracleLinux 8+, RockyLinux 8+, AstraLinux CE and Arch as fully supported. FreeBSD is half-supported and needs pkg install -y curl bash first, and Armbian is also half-supported.
Can I run spiritLHLS/ecs without the interactive menu?
Yes. The README documents a parameter mode using -m, for example bash ecs.sh -m 1 for the full test, and states that up to three levels can be specified. Flags such as -en, -base, -ctype, -dtype, -mdisk, -stype, -bansp and -banup adjust what runs and how output is produced.
Is it safe to run spiritLHLS/ecs on a production server?
The README states the project updates the package manager by default and warns not to use it in a production environment. It also recommends running from /root to avoid environment dependency issues, which is the opposite of a minimal-impact tool.
Where does spiritLHLS/ecs save its results?
The README says results are saved to test_result.txt in the current path. The full and lite versions also upload results to pastebin and return a share link, unless you pass -banup to suppress link generation.
Community notes