ecs and the side effects of running a fused VPS benchmark on your own box

The fused run stitches together six upstream test scripts

The Shell build of ecs does not implement its own CPU, IO, streaming or route measurement. It assembles them. The dd disk read and write test comes from LemonBench, the fio disk test comes from YABS, and the default CPU number is a sysbench score rather than a Geekbench result. Streaming unlock data is printed twice, once from a Go compiled binary and once from a shell script, so the two can be compared side by side. TikTok region checks exist in two variants, superbench and lmc999, and the project warns that whichever one breaks may be replaced by the other, which means a result you pasted from an older run may not match what the script does now.

The return route test uses a Go compiled binary plus a version contributed by a friend through a pull request, adapted to several IP lists. Basic system information goes further than bench.sh, superbench.sh and YABS by adding systl, NAT type detection and a concurrent ASN lookup. Several stages run in parallel, which the project puts at two to three minutes saved against purely sequential execution.

Fetching ecs.sh from GitHub or GitLab, and where the output lands

Run it under the /root path, the project advises, and pick one of five invocations. The first pulls the script from a GitLab repository, marks it executable and starts it:

curl -L https://gitlab.com/spiritysdx/za/-/raw/main/ecs.sh -o ecs.sh && chmod +x ecs.sh && bash ecs.sh

Three shorter forms pipe the script straight into bash through hostnames the project keeps pointed at its own mirrors:

bash <(wget -qO- bash.spiritlhl.net/ecs)

With no arguments the script opens its interactive menu. FreeBSD counts as only half supported and needs curl and bash present before anything else:

pkg install -y curl bash

Output lands in test_result.txt in the directory you launched from, so run it inside screen or tmux and disconnect instead of leaving an SSH session open. The project notes that the CDN it uses for environment installation and prebuilt file downloads can be slow inside China, so a stalled download points at connectivity rather than a dead link.

-m 1 is the whole battery, and the menu goes three levels deep

Parameter mode exists for servers where nobody can answer a menu prompt. The switch table lists -m as the only required option and allows up to three levels of selection, so `bash ecs.sh -m 5 1 1` runs the first sub-sub item under main menu entry 5. `-m 1` selects the complete fused test, and the project says `-m 1 0` and `-m 1 0 0` mean the same thing. Download once, then run it repeatedly:

curl -L https://gitlab.com/spiritysdx/za/-/raw/main/ecs.sh -o ecs.sh && chmod +x ecs.sh

bash ecs.sh -m 1

The per-test flags decide what gets measured. -base narrows the run to basic system information only. -ctype moves the CPU test off sysbench and onto a named Geekbench version, gb4, gb5 or gb6. -dtype picks dd or fio, and with neither flag both run. -mdisk widens disk IO testing to every mounted disk including the system disk, where the default touches only the system disk. -stype chooses between .cn and .net speed test data, and the default tries .net first, substituting .cn only when .net is unusable. -bansp forces the speed test off, -banup suppresses the share link, and output is Chinese unless you pass -en.

Route targets are four cities and their IPv6 twins, nothing else

The return route test needs a destination. -i takes a literal IPv4 address, and the project suggests finding one through ip.sb or ipinfo.io when you want a specific path traced. -r uses city codes instead: b, g, s and c stand for Beijing, Guangzhou, Shanghai and Chengdu. For Beijing, Guangzhou and Shanghai, appending a 6 (b6, g6, s6) switches to that city's IPv6 address, so -r b6 tests Beijing IPv6 across the three carriers while -r b tests Beijing IPv4; Chengdu has no IPv6 code.

The city set is closed: the parameter table carries no code for any other city, so for any other destination you pass a specific IPv4 address with -i.

It updates your package manager before the first measurement

This is the part worth reading twice. The project states that ecs.sh updates the package manager by default, and says plainly that it should not be used in production. On a machine hosting anything, that default is the entire risk: the run changes the machine's package setup, which is why the project recommends the Go version to keep the local configuration unchanged. The project's own answer is the Go rewrite it now recommends, oneclickvirt/ecs, described as needing no extra environment dependencies, referencing no third party shell files and supporting runs without root.

The Shell build does offer a cleanup route. Pressing Ctrl+C ends the test, and the script then deletes the leftover dependency files it installed. That only helps if you notice and send the interrupt. Otherwise both the full and lite versions upload the finished result to a pastebin and hand back a share link, so a benchmark you never meant to publish leaves a public URL, unless you pass -banup.

dd finishes fast, fio tells a truer story more slowly

The two disk tests answer different questions, and the project says which is which. The dd test came from LemonBench: quick, no disk size limit, and prone to large error. The fio test came from YABS: closer to real behaviour, slower, and bounded by how much disk and memory the machine has, which is precisely the situation in which you are testing a small VPS. -dtype selects one; the default runs both. That default is the safer read because the two numbers rarely agree, and a single disk figure in a pasted result tells you which test produced it only if you know which one ran.

The CPU side has the same shape. sysbench is the default, chosen over the Geekbench versions YABS uses, so a sysbench score sitting in test_result.txt is not comparable with a Geekbench number from another script. -ctype gb4, gb5 or gb6 switches the engine. The project's example of its weakest test machine took 47 minutes to finish.

The ipcheck.sh in the repository is the reduced one

IP reputation runs as its own script with three entry points. The shortest pipes it through the same mirror host:

bash <(wget -qO- bash.spiritlhl.net/ecs-ipcheck)

A second skips certificate checking, applied here to the raw GitHub file:

bash <(wget -qO- --no-check-certificate https://raw.githubusercontent.com/spiritLHLS/ecs/main/ipcheck.sh)

The third downloads the file so you can read it first, and needs dos2unix installed before the script will run:

wget -qO ipcheck.sh --no-check-certificate https://gitlab.com/spiritysdx/za/-/raw/main/ipcheck.sh
dos2unix ipcheck.sh
bash ipcheck.sh

Coverage is stated plainly: fifteen database lookups, DNS blacklist checks, IPv4 and IPv6 checks, ASN and address lookups, and mail port detection. The project points at the IP2Location type field for a quick read, and notes that a reachable port 25 means a mail server is possible. What the check does not do matters just as much. The IP quality check fused into ecs.sh is a simplified version with no Cloudflare threat score, and the standalone script above is the complete one. Reading the fused output as the full verdict on an address is a mistake.

Half supported systems, and a Shell build kept for maintenance

The compatibility table splits the field in two. Ubuntu 18+, Debian 8+, Centos 7+, Fedora 33+, Almalinux 8.5+, OracleLinux 8+, RockyLinux 8+, AstraLinux CE and Arch are fully supported. FreeBSD and Armbian are half supported, FreeBSD only after curl and bash are installed. Architectures cover amd64 (x86_64), arm64, i386 and arm, and the stated condition for every region is simply a working internet connection, since a machine with no public network cannot be tested. That last row is the practical filter, because a box behind a firewall with no egress produces nothing worth reading.

Release history is thinner than the feature list suggests. The repository has no GitHub releases, so the trail runs through CHANGELOG.md, where the 2026.08.27 entry records the speedtest-go download moving to v1.8.3. The last push was on 2026-10-22. The project states that the Shell version takes no new features and stays for maintenance, with every test rebuilt in Go, and it routes readers who hit a native OS bug to the one-click-installation-script repository, with script bugs going to its own issue tracker, and suggests the Go version for dependency errors or systems and architectures it does not list. The repository is MIT licensed.

Editorial conclusion

Adopt ecs.sh when the machine under test is yours alone and you want every measurement collected into test_result.txt plus a shareable link in a single pass. Leave it alone on production, or on anything where a package upgrade would matter, and use the Go build at oneclickvirt/ecs instead. Verify two things before the first run: that the host has public network egress, because the project states a machine without one cannot be tested, and that the box can survive the default package manager update.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. spiritLHLS/ecs on GitHub