Welche VPS-Specs brauche ich für Web-Scraping?

Hängt vom Stack ab. Ein einfacher HTTP-Scraper (httpx/requests, der APIs oder statisches HTML ansteuert) ist leicht — ein 3-$-Nano mit 1 GB ist reichlich. In dem Moment, in dem du einen echten Browser für JavaScript-lastige Seiten brauchst, will Playwright mit headless Chromium 2–4 GB: ein 5-$-Micro für ein oder zwei Browser-Kontexte, ein 8-$-Small, wenn du mehrere parallel betreibst. Chromium ist der RAM-Fresser, nicht dein Code.

Kann ich von der eigenen IP des Servers scrapen, oder brauche ich Proxys?

Für Scraping mit geringem Volumen und gutem Benehmen von Seiten, die es erlauben, ist die IP des Servers in Ordnung. Im großen Maßstab oder gegen Seiten, die per IP rate-limitieren, brauchst du einen externen Proxy-Pool — eine IP (geteilt oder dediziert) kann die Last nicht verteilen, und von einer einzelnen Adresse zu hämmern lässt sie schnell blockieren. Eine dedizierte IP gibt dir einen sauberen Ruf, den du kontrollierst; Proxys geben dir viele.

Cron oder systemd-Timer für geplante Scrapes?

Ein systemd-Timer, in fast jedem Fall. Anders als Cron gibt er dir ordentliches Logging über journalctl, Abhängigkeits-Ordnung, automatisches Nachholen, falls die Maschine unten war, und Pro-Lauf-Status, den du inspizieren kannst. Cron funktioniert noch für todeinfache Jobs, aber ein Timer ist der bessere Standard auf einem Server, den du tatsächlich wartest.

Ist Web-Scraping auf dem VPS erlaubt?

Legales, respektvolles Scraping — ja. Aggressives Scraping, das Rate-Limits oder robots.txt ignoriert oder darauf hinausläuft, ein Ziel in einen Denial of Service zu hämmern, ist ein Verstoß gegen die Nutzungsbedingungen und führt zur Beendigung des Dienstes. Scrape, was dir erlaubt ist, drossle dich selbst und mach aus einem Scraper keinen Angriff.

VPS für Web-Scraping: Einrichtung, Dimensionierung und ehrliche Grenzen

Ein Scraper auf deinem Laptop ist in Ordnung, bis du ihn mitten im Lauf schließt, deine Heim-IP rate-limitiert wird oder du willst, dass derselbe Job jede Stunde läuft, ob du wach bist oder nicht. Ihn auf einen VPS zu verschieben behebt alle drei: er bleibt 24/7 oben, er verbrennt nicht den Ruf deiner Heim-IP, und Cron oder ein systemd-Timer betreibt ihn nach Zeitplan ohne dich. Hier ist, wie man das einrichtet, wie viel Server du tatsächlich brauchst, und die Teile, die die meisten Leitfäden still überspringen.

Warum ein VPS deine Maschine hierfür schlägt

24/7 und geplant. Ein Scraper, der stündlich läuft, braucht einen Host, der immer an ist. Ein Laptop ist es nicht.
Deine Heim-IP bleibt sauber. Von zu Hause zu scrapen bedeutet, dass deine Wohn-IP die Rate-Limits und Blockaden abbekommt. Tu es von einem Server und deine eigene Verbindung bleibt unberührt.
Stabilität. Kein Ruhezustand, kein WLAN-Wegfall mitten im Crawl, eine stetige Rechenzentrums-Verbindung, und ein Ort, um Ergebnisse zu sammeln.

Der Stack, und was jeder Teil braucht

Zwei sehr verschiedene Gewichtsklassen, und den falschen Plan zu wählen verschwendet Geld oder hungert den Job aus:

httpx / requests (Python) — für APIs, JSON-Endpunkte und statisches HTML. Das ist leicht: der Prozess sitzt in Dutzenden von Megabyte, netzwerkgebunden, nicht CPU-gebunden. Ein 3-$-Nano (1 vCPU / 1 GB) betreibt das bequem, sogar mit Nebenläufigkeit über asyncio.
Playwright / headless Chromium — für JavaScript-gerenderte Seiten, wo du einen echten Browser brauchst. Das ist der schwere. Headless Chromium ist grob 300–400 MB pro Browser-Instanz, plus 100–200 MB pro offenem Kontext/Tab, plus deine Laufzeit. Kalkuliere:
- 5-$-Micro (2 vCPU / 2 GB) — ein oder zwei Browser-Kontexte gleichzeitig.
- 8-$-Small (4 vCPU / 4 GB) — mehrere parallele Kontexte oder schwerere Seiten.

Die Faustregel: dein Code ist fast nie der Engpass — Chromium ist es. Dimensioniere für den Browser, nicht für den Scraper.

Zeitplanung: systemd-Timer statt Cron

Cron funktioniert, aber ein systemd-Timer ist der bessere Standard auf einem Server, den du wartest: Logs über journalctl, Nachholen, falls die Maschine unten war, und inspizierbarer Pro-Lauf-Status. Ein minimales Setup:

# /etc/systemd/system/scrape.service
[Unit]
Description=Run scraper
[Service]
Type=oneshot
User=scraper
WorkingDirectory=/home/scraper/job
ExecStart=/home/scraper/job/venv/bin/python scrape.py

# /etc/systemd/system/scrape.timer
[Unit]
Description=Hourly scrape
[Timer]
OnCalendar=hourly
Persistent=true
[Install]
WantedBy=timers.target

sudo systemctl enable --now scrape.timer
journalctl -u scrape.service -f   # sieh Läufen zu

Persistent=true ist das, was Cron nicht kann: wenn der Server zur Laufzeit aus war, feuert der Job einmal beim Booten, statt still zu überspringen.

Wohin die Ergebnisse gehen

Halte es einfach und passe es dem Volumen an: SQLite für strukturierte Daten, die du abfragen wirst (eine Datei, null Einrichtung), CSV für schnelle tabellarische Dumps, oder ein S3-kompatibler Object-Store, wenn die Ergebnisse die Maschine überwachsen oder du sie vom Server weg willst. Rotiere deine Logs (logrotate oder journald-Limits), damit ein gesprächiger Scraper nicht langsam die Festplatte füllt.

Der ehrliche Teil: Egress-IP und Ruf

Das ist das Detail, das entscheidet, ob dein Scraper eine Woche funktioniert oder am ersten Tag blockiert wird.

Bei einem NAT-Plan teilt sich ausgehender Traffic eine Egress-IP mit anderen Kunden. Der Ruf dieser IP ist geteilt — ein Nachbar, der dasselbe Ziel scrapt, kann die Adresse rate-limitieren lassen, bevor du eine einzige Anfrage sendest. Gut für leichtes, gelegentliches Scraping; eine Belastung bei Volumen.

Eine dedizierte IP gibt dir deinen eigenen Egress-Ruf — das Verhalten von niemand anderem beeinflusst ihn. Aber es schneidet in beide Richtungen: aggressives Scraping verbrennt deine eigene saubere IP, und sobald ein Ziel sie blockiert, ist sie blockiert. Eine dedizierte IP ist Kontrolle, keine Immunität.

Im echten Maßstab brauchst du externe Proxy-Pools. Keine einzelne IP — geteilt oder dediziert — kann die Last über viele Adressen verteilen, was ernsthaftes Scraping gegen IP-rate-limitierte Ziele erfordert. Proxys sind eine generische Drittanbieter-Schicht, die du obendrauf hinzufügst; der VPS betreibt den Scraper, der Proxy-Pool liefert die Adressen. Erwarte nicht, dass eine Server-IP den Job eines Proxy-Pools macht.

Ethik und die AUP — nicht optional

Scraping lebt in einer rechtlichen und ethischen Grauzone, also sei klaräugig:

Respektiere Rate-Limits und robots.txt. Drossle deine Anfragen. Ein höflicher Scraper sieht aus wie Traffic; ein unhöflicher sieht aus wie ein Angriff.
Mach keinen DoS auf dein Ziel. Eine Seite zu hämmern, bis sie umfällt, ist kein Scraping, es ist ein Denial-of-Service — und es ist hier ein Verstoß gegen die Nutzungsbedingungen, der zur Beendigung des Dienstes führt.
Scrape nur, was dir erlaubt ist. Legale, erlaubte Datensammlung ist die Grenze. Überschreite sie und es liegt an dir.

Das Fazit

Ein VPS ist das richtige Zuhause für einen Scraper: immer an, geplant und weg von deiner Heim-IP. Passe den Plan an den Stack an — 3-$-Nano für httpx, 5-$-Micro bis 8-$-Small für Playwright — plane mit einem systemd-Timer, und sei ehrlich über IPs: geteilter Egress teilt Ruf, eine dedizierte IP ist deine, um sie aufzubauen oder zu verbrennen, und echter Maßstab bedeutet Proxy-Pools. Riegle die Maschine zuerst mit der Neuer-VPS-Sicherheits-Checkliste ab, dimensioniere sie richtig mit dem VPS-Dimensionierungs-Leitfaden, und wenn dir Zahlen-ohne-Karte-Privatsphäre wichtig ist, ist die Aufschlüsselung zum anonymen VPS die ehrliche Version. Scrape verantwortungsvoll — die AUP ist real.

Bereit zu scrapen? Ein Micro-Plan ist ein solider Start; große nebenläufige Crawls machen sich besser auf Small.