netcup-Traffic im Blick: Drosselung mit vnstat, ntfy und SCP-API erkennen

In den Produktdaten des netcup VPS 500 G12.5 steht beim Traffic eine Grenze: „Wenn der durchschnittliche Netzwerkverkehr der letzten 24 Stunden 2 TB überschreitet, erfolgt eine vorübergehende Drosselung auf 200 MBit/s.“ Wer große Backups schiebt oder Downloads anbietet, sollte wissen, wie viel in den letzten 24 Stunden durch die Leitung ging. Diese Anleitung zeigt, wie Sie das mit vnstat auf dem Server messen, sich per ntfy warnen lassen, bevor die Grenze erreicht ist, und die Werte über die SCP-REST-API von netcup gegenprüfen. Dabei stolpern Sie auf einem netcup-VPS über eine Voreinstellung von vnstat, die große Teile des Verkehrs stillschweigend verwirft.

Dies ist Teil 19 der Reihe „netcup Spezial“.

Als Beispiel dient ein netcup-VPS mit Ubuntu und Docker.

Was die 2-TB-Grenze bedeutet

2 TB in 24 Stunden entsprechen im Schnitt rund 185 MBit/s, und das rund um die Uhr. Die Netzwerkschnittstelle des VPS 500 G12.5 ist laut netcup mit 2,5 GBit/s angebunden. Bei voller Geschwindigkeit sind 2 TB damit nach etwas weniger als zwei Stunden erreicht. Im Test lud der Server eine 1-GiB-Datei in knapp vier Sekunden, also mit rund 2,3 GBit/s. Bei einer großen Rücksicherung oder einem Umzug ist die Grenze also erreichbar.

Aus dem Wortlaut geht nicht hervor, ob netcup eingehenden und ausgehenden Verkehr zusammenzählt. Die Skripte in dieser Anleitung addieren deshalb beide Richtungen. So warnen sie eher zu früh als zu spät.

Voraussetzungen

• Ein netcup-VPS mit Ubuntu und root-Zugang
• Ein Thema bei ntfy, entweder auf dem öffentlichen Dienst ntfy.sh oder auf einem eigenen ntfy-Server, wie in ntfy mit Docker installieren beschrieben, dazu die ntfy-App auf dem Handy
• Für die Gegenprobe über die SCP-REST-API: ein zweiter Linux- oder macOS-Rechner mit curl und jq sowie Ihr Login für das Server Control Panel (SCP)

Die Befehle auf dem Server führen Sie als root oder mit sudo aus.

Schritt 1: vnstat installieren und auf eth0 beschränken

vnstat liest die Zähler des Kernels und läuft als sparsamer Dienst:

apt-get install -y vnstat jq
vnstat --version

vnStat 2.12 by Teemu Toivola <tst at iki dot fi> (SQLite 3.45.1)

Beim ersten Start nimmt vnstat alle Schnittstellen auf, die es findet. Auf einem Server mit Docker sind das neben eth0 die Bridges und die veth-Interfaces der Container. Im Journal stand bei uns:

vnstatd[1921614]: Interface "docker0" added with 1000 Mbit bandwidth limit.
vnstatd[1921614]: Interface "veth433e49d" added with 10000 Mbit bandwidth limit.
vnstatd[1921614]: -> 10 new interfaces found.

Für die netcup-Grenze zählt nur, was über die Netzwerkkarte nach außen geht. Container-Verkehr läuft ohnehin auch über eth0 und würde sonst doppelt erscheinen. Entfernen Sie deshalb alle Einträge außer eth0:

for i in $(vnstat --dbiflist 1 | tr " " "\n" | grep -v "^eth0$"); do
  vnstat --remove -i "$i" --force
done
sed -i 's/^;Interface ""/Interface "eth0"/' /etc/vnstat.conf

Die letzte Zeile setzt eth0 nur als Standard für Abfragen, beschränkt wird die Erfassung durch das Entfernen. Den Namen Ihrer Schnittstelle zeigt ip -br link. Neue Container-Interfaces kommen danach nicht mehr dazu, denn AlwaysAddNewInterfaces steht in der Standardkonfiguration auf 0. vnstat nimmt neue Schnittstellen nur beim allerersten Start mit leerer Datenbank selbst auf.

Verifizieren: vnstat --dbiflist zeigt nur noch Interfaces in database: eth0.

Schritt 2: MaxBandwidth an die netcup-Schnittstelle anpassen

Dieser Schritt ist der wichtigste. vnstat prüft jeden Messwert auf Plausibilität: Ist der Verkehr zwischen zwei Abfragen höher, als die Schnittstelle schaffen kann, hält vnstat ihn für einen Zählerfehler und verwirft ihn. Die Geschwindigkeit der Schnittstelle liest vnstat aus dem System. Bei der virtuellen Netzwerkkarte von netcup steht dort aber nichts Brauchbares:

cat /sys/class/net/eth0/speed

-1

vnstat fällt dann auf MaxBandwidth 1000 zurück, also 1 GBit/s. Im Test haben wir dreimal eine 1-GiB-Datei geladen, mit rund 2,3 GBit/s. Das Journal meldete:

vnstatd[1922341]: Info: Traffic rate for "eth0" higher than set maximum 1000 Mbit (20s->2673868800, r3233909422 t7985574, 64bit:1), syncing.

Hinter dem harmlos klingenden „syncing“ steckt, dass vnstat den Zeitraum nicht zählt. Im 5-Minuten-Wert standen danach 231 MiB statt gut 3 GiB. Setzen Sie den Wert deshalb über die 2,5 GBit/s der netcup-Schnittstelle:

sed -i 's/^;MaxBandwidth 1000/MaxBandwidth 3000/' /etc/vnstat.conf
systemctl restart vnstat
journalctl -u vnstat -n 1 --no-pager

vnstatd[1929177]: Info: Monitoring (1): eth0 (3000 Mbit)

Derselbe Test mit drei Downloads danach: vnstat zählte 3.233.967.654 Bytes mehr, der 5-Minuten-Wert stieg um gut 3 GiB, und im Journal tauchte keine Verwerfung mehr auf.

Verifizieren: journalctl -u vnstat | grep -i "higher than set maximum" liefert nach einem großen Download keine neue Zeile.

Schritt 3: Die letzten 24 Stunden summieren

Die Anzeigen von vnstat sind nach Tag und Stunde gegliedert. Der Produkttext spricht dagegen von den letzten 24 Stunden, die Skripte rechnen deshalb mit einem gleitenden Fenster. Die 5-Minuten-Werte bewahrt vnstat in der Standardkonfiguration 48 Stunden lang auf (5MinuteHours 48), das reicht für eine gleitende Summe. Die JSON-Ausgabe hat für jeden Eintrag einen Unix-Zeitstempel:

vnstat -i eth0 --json f | jq '[.interfaces[0].traffic.fiveminute[]
  | select(.timestamp >= (now - 86400)) | .rx + .tx] | add // 0'

Das Ergebnis sind Bytes, // 0 liefert bei leerer Datenbank 0 statt null.

Wichtig für Tests: vnstat schreibt seine Datenbank nur alle fünf Minuten (SaveInterval 5). Direkt nach einem Download zeigte die Abfrage bei uns noch den alten Wert, nach knapp fünf Minuten den neuen.

Verifizieren: Die Abfrage liefert eine Zahl statt null. Nach einem Download von 1 GiB steigt sie spätestens nach fünf Minuten um rund 1,07 Milliarden.

Schritt 4: Warnung per ntfy

Legen Sie die Einstellungen in eine eigene Datei, die nur root lesen darf. Das ntfy-Thema wirkt wie ein Passwort: Wer den Namen kennt, kann auf ntfy.sh mitlesen und selbst Nachrichten hineinschreiben. Nehmen Sie deshalb einen langen Zufallsnamen oder Ihren eigenen ntfy-Server:

echo "traffic-$(openssl rand -hex 8)"
(umask 077; nano /etc/traffic-check.env)

GRENZE_GB=1500
NTFY_URL=https://ntfy.sh/traffic-3f9a1c7e5b20d84a

Bedenken Sie die Verzögerung: Das Skript läuft alle 15 Minuten, und vnstat speichert nur alle fünf Minuten. Eine Warnung kann also rund 20 Minuten nach dem Überschreiten kommen. Bei voller Geschwindigkeit sind in dieser Zeit mehrere hundert Gigabyte übertragen. 1500 GB lassen gut 500 GB Luft. Erwarten Sie Dauerlast nahe der Grenze, wählen Sie eine niedrigere Schwelle. Das Skript nach /usr/local/bin/traffic-check:

#!/bin/sh
# Summe rx+tx der letzten 24 Stunden aus vnstat, Warnung per ntfy ab einer Grenze
set -eu
. /etc/traffic-check.env
IF="${IF:-eth0}"
STATUS=/var/lib/traffic-check.status

BYTES=$(vnstat -i "$IF" --json f | jq '[.interfaces[0].traffic.fiveminute[]
  | select(.timestamp >= (now - 86400)) | .rx + .tx] | add // 0')
GB=$((BYTES / 1000000000))
echo "$(date '+%F %T') letzte 24 h: $GB GB (Grenze $GRENZE_GB GB)"

if [ "$GB" -ge "$GRENZE_GB" ]; then
  # nur einmal melden, bis der Wert wieder unter die Grenze fällt
  if [ ! -f "$STATUS" ]; then
    curl -fsS -H "Title: Traffic $(hostname)" -H "Priority: high" -H "Tags: warning" \
      -d "Letzte 24 Stunden: $GB GB, Grenze $GRENZE_GB GB. netcup drosselt ab 2 TB im 24-Stunden-Schnitt." \
      "$NTFY_URL" >/dev/null
    touch "$STATUS"
    echo "Warnung gesendet"
  fi
elif [ -f "$STATUS" ]; then
  curl -fsS -H "Title: Traffic $(hostname)" -H "Tags: white_check_mark" \
    -d "Wieder unter der Grenze: $GB GB in den letzten 24 Stunden." "$NTFY_URL" >/dev/null
  rm -f "$STATUS"
  echo "Entwarnung gesendet"
fi

Die Statusdatei verhindert, dass alle 15 Minuten eine neue Warnung kommt. Scheitert der Versand an ntfy, bricht das Skript wegen set -e vor dem Anlegen der Statusdatei ab und versucht es beim nächsten Lauf erneut. Die Werte rechnet das Skript in Gigabyte zu 10⁹ Bytes, die Anzeigen von vnstat arbeiten dagegen mit GiB.

chmod 755 /usr/local/bin/traffic-check
traffic-check

2026-11-05 10:08:50 letzte 24 h: 4 GB (Grenze 1500 GB)

Zum Testen setzen Sie GRENZE_GB kurz unter den aktuellen Wert, bei uns auf 3. Der erste Lauf meldete „Warnung gesendet“, ein zweiter Lauf direkt danach schickte nichts. Mit der Grenze wieder auf 1500 kam „Entwarnung gesendet“. Beide Nachrichten erschienen in ntfy:

Verifizieren: Nach dem Test steht GRENZE_GB wieder auf Ihrem echten Wert und /var/lib/traffic-check.status existiert nicht.

Schritt 5: Alle 15 Minuten prüfen

cat > /etc/cron.d/traffic-check <<'EOF'
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
*/15 * * * * root /usr/local/bin/traffic-check >> /var/log/traffic-check.log 2>&1
EOF

Die PATH-Zeile stellt sicher, dass cron alle Programme findet, auch das Skript unter /usr/local/bin.

Verifizieren: Nach der nächsten Viertelstunde steht eine Zeile im Log:

2026-11-05 10:15:01 letzte 24 h: 4 GB (Grenze 1500 GB)

Schritt 6: Gegenprobe über die SCP-REST-API

netcup misst den Verkehr auch selbst, und das SCP gibt diese Werte über seine REST-API heraus. Zwei Dinge liefert die API zusätzlich: das Feld trafficThrottled, das dem Namen nach den Drosselstatus der Schnittstelle angibt, und eine Messung, die nicht vom Server selbst stammt. Im Test stand das Feld auf false. Führen Sie diesen Teil auf einem anderen Rechner aus, nicht auf dem VPS. Der Zugang gilt für das ganze SCP-Konto, nicht nur für einen Server. Unser Konto zeigte über die API alle sechs Server des Kontos, und mit dem Token lassen sich Server auch stoppen oder Snapshots zurückspielen.

Die Anmeldung läuft über einen Gerätecode. Fordern Sie ihn an:

curl -s https://www.servercontrolpanel.de/realms/scp/protocol/openid-connect/auth/device \
  -d client_id=scp -d "scope=offline_access openid" | tee device.json | jq '{verification_uri_complete, expires_in}'

Öffnen Sie die angezeigte Adresse im Browser, melden Sie sich mit Ihrem SCP-Login an und bestätigen Sie den Code. Er gilt laut Antwort 600 Sekunden. Erst nach der Bestätigung im Browser holen Sie das Token ab und legen nur den Refresh-Token in einer geschützten Datei ab:

mkdir -p ~/.config/netcup-scp && chmod 700 ~/.config/netcup-scp
curl -s https://www.servercontrolpanel.de/realms/scp/protocol/openid-connect/token \
  -d client_id=scp -d grant_type=urn:ietf:params:oauth:grant-type:device_code \
  -d "device_code=$(jq -r .device_code device.json)" \
  | jq -r .refresh_token > ~/.config/netcup-scp/refresh_token
chmod 600 ~/.config/netcup-scp/refresh_token
head -c 20 ~/.config/netcup-scp/refresh_token; echo
rm device.json

Steht in der Datei null, war die Bestätigung noch nicht abgeschlossen. Holen Sie das Token dann erneut ab, bevor Sie device.json löschen.

Laut Antwort des Anmeldedienstes gilt ein Zugriffs-Token 300 Sekunden, der Refresh-Token 2.592.000 Sekunden, also 30 Tage. Planen Sie spätestens nach 30 Tagen ohne Nutzung eine neue Anmeldung ein. Im SCP können Sie unter API bei den Einstellungen zur REST-API zusätzlich einen IP-Filter setzen, damit nur Ihre Adressen die API nutzen dürfen.

Die Server-ID finden Sie mit GET https://www.servercontrolpanel.de/scp-core/api/v1/servers oder im SCP. Das Skript traffic-api.sh:

#!/bin/sh
# Drosselstatus und 24-Stunden-Summe über die netcup-SCP-REST-API
set -eu
SERVER_ID="$1"
TOKENDATEI="${TOKENDATEI:-$HOME/.config/netcup-scp/refresh_token}"
KC=https://www.servercontrolpanel.de/realms/scp/protocol/openid-connect/token
API=https://www.servercontrolpanel.de/scp-core/api/v1

ACCESS=$(curl -fsS "$KC" -d client_id=scp -d grant_type=refresh_token \
  --data-urlencode "refresh_token=$(cat "$TOKENDATEI")" | jq -r .access_token)

curl -fsS -H "Authorization: Bearer $ACCESS" "$API/servers/$SERVER_ID" |
  jq -r '.serverLiveInfo.interfaces[] |
    "Gedrosselt: \(.trafficThrottled), Monat rx \(.rxMonthlyInMiB) MiB, tx \(.txMonthlyInMiB) MiB"'

# Werte sind Bytes pro Sekunde; bis 6 h im Minutenraster, darüber im 10-Minuten-Raster
curl -fsS -H "Authorization: Bearer $ACCESS" "$API/servers/$SERVER_ID/metrics/network?hours=24" |
  jq -r 'to_entries | sort_by(.key)
    | ((.[1].key | fromdateiso8601) - (.[0].key | fromdateiso8601)) as $schritt
    | (map(.value | to_entries | map(.value) | add) | add // 0) * $schritt / 1e9
    | "Letzte 24 h laut SCP: \(. * 100 | round / 100) GB (Raster \($schritt) s)"'

sh traffic-api.sh 123456

Gedrosselt: false, Monat rx 2760 MiB, tx 50 MiB
Letzte 24 h laut SCP: 9.79 GB (Raster 600 s)

Die API-Beschreibung sagt nur, dass metrics/network je Zeitstempel einen Wert pro Schnittstelle liefert. In der Antwort standen je Schnittstelle die Schlüssel IN und OUT. Die Einheit haben wir aus dem Test abgeleitet: Für die Minute mit dem zweiten Durchgang der drei Downloads (09:03 UTC) stand dort für die Richtung IN der Wert 53.897.970. Mal 60 Sekunden ergibt das 3,23 GB, genau die geladene Menge. Es sind also Bytes pro Sekunde, gemittelt über das Raster.

Das Raster selbst wechselt mit dem Zeitraum. Bei hours=1, 3 und 6 kam bei uns ein Wert pro Minute, bei hours=12 und 24 ein Wert alle zehn Minuten. Wer pauschal mit 60 Sekunden rechnet, unterschätzt den Verkehr über 24 Stunden um den Faktor zehn. Das Skript liest den Abstand deshalb aus den ersten beiden Zeitstempeln. Die Zeitstempel sind in UTC, vnstat zeigt Ortszeit. Die Ausgabe von jq verwendet einen Dezimalpunkt statt eines Kommas.

Die Monatswerte rxMonthlyInMiB und txMonthlyInMiB haben sich im Test auch nach mehr als 6 GB Verkehr nicht bewegt. Sie eignen sich deshalb nicht für eine zeitnahe Kontrolle.

Verifizieren: Vergleichen Sie beide Messungen für dasselbe Zeitfenster. Bei uns zeigte das SCP für 09:55 bis 10:10 Uhr 7,37 GB, vnstat 4,13 GB. Die Differenz von 3,24 GB ist genau der erste Download, den vnstat vor der Korrektur in Schritt 2 verworfen hatte. Den zweiten Download nach der Korrektur zählten beide gleich, mit 3,23 GB.

Typische Fehler

Meldung	Ursache und Lösung
Traffic rate for "eth0" higher than set maximum 1000 Mbit … syncing.	vnstat verwirft Verkehr über 1 GBit/s. MaxBandwidth 3000 setzen, siehe Schritt 2.
Summe ändert sich nach einem Download nicht	vnstat schreibt die Datenbank nur alle fünf Minuten. Nach dem nächsten Speichern erneut abfragen.
curl: (22) The requested URL returned error: 400	Die ntfy-Adresse ist unvollständig, im Test fehlte das Thema hinter https://ntfy.sh/. NTFY_URL in /etc/traffic-check.env prüfen.
SCP-Summe viel zu niedrig	Mit 60 Sekunden statt mit dem tatsächlichen Raster gerechnet. Bei hours=12 und 24 lieferte die API 10-Minuten-Werte.

Häufige Fragen

Zählt netcup eingehenden und ausgehenden Verkehr zusammen?

Die Produktdaten sprechen nur vom „durchschnittlichen Netzwerkverkehr der letzten 24 Stunden“. Ob beide Richtungen addiert werden, steht dort nicht. Die Skripte addieren beide und sind damit auf der sicheren Seite.

Was passiert, wenn die Grenze überschritten ist?

Laut netcup wird der Server vorübergehend auf 200 MBit/s gedrosselt, und die Drosselung wird aufgehoben, sobald die Bedingung nicht mehr zutrifft. Da 200 MBit/s über dem Schnitt von rund 185 MBit/s liegen, kann die Drosselung bei anhaltender Last bestehen bleiben. Als Hinweis auf den Status dient das Feld trafficThrottled aus Schritt 6.

Warum nicht nur die SCP-API?

Die API schickt keine Nachricht von selbst, Sie müssten sie regelmäßig abfragen. Dafür bräuchte der abfragende Rechner dauerhaft einen Token mit vollem Zugriff auf alle Server des Kontos. vnstat auf dem Server kommt ohne solchen Zugang aus.

Gilt die Grenze für alle netcup-Tarife?

Der zitierte Satz stammt aus den Produktdaten des VPS 500 G12.5. Für andere Tarife gilt die Angabe „Traffic“ des jeweiligen Produkts, die Schwelle passen Sie über GRENZE_GB an.

Fazit

Die Traffic-Grenze von netcup ist großzügig, aber mit einer 2,5-GBit/s-Schnittstelle in wenigen Stunden erreichbar. vnstat mit einem kleinen Skript und ntfy warnt rechtzeitig, allerdings erst, nachdem Sie MaxBandwidth angepasst haben. Ohne diese Zeile hätte vnstat im Test fast die Hälfte des Verkehrs im Messzeitraum verschluckt, ohne dass es in der normalen Anzeige auffällt. Die SCP-REST-API ist die unabhängige Gegenprobe. Sie hat genau diesen Fehler sichtbar gemacht und liefert mit trafficThrottled einen Hinweis auf den Drosselstatus.

Weiterführende Anleitungen und Quellen

• ntfy mit Docker installieren: eigener Server für Push-Nachrichten
• Teil 4: SCP-Einstellungen, CPU-Topologie und UEFI
• Teil 5: Das SCP-Protokoll lesen
• Teil 10: Steal-Time auf dem netcup-VPS messen
• netcup: VPS-Übersicht mit Produktdaten (Angabe „Traffic“)
• netcup: REST-API im SCP
• SCP-REST-API: OpenAPI-Beschreibung
• vnStat: Handbuch zu vnstat.conf
• ntfy: Nachrichten senden