Warum gibt es keine Fehlermeldung, wenn Chrome eine Regel ignoriert?

Das ist Absicht, kein Bug. Chrome's declarativeNetRequest API gibt Erweiterungen absichtlich keine Rückmeldung über abgelehnte Regelanwendungen — das Sicherheitsmodell soll verhindern, dass Extensions browserinternes Verhalten ausspionieren können. Die Regel wird einfach übergangen.

Welche Header sind typischerweise gesperrt?

Chrome schützt eine Reihe von Headern: Host, Content-Length, Content-Transfer-Encoding, Trailer, Te, Upgrade, Cookie2, Keep-Alive, Origin und Set-Cookie gehören dazu. Die vollständige Liste liegt in der Chrome-Extension-Dokumentation — sie kann sich mit Chrome-Versionen ändern.

Kann Header Modifier auch Response-Header verändern?

Nein. Header Modifier ändert ausschließlich Request-Header — also was dein Browser an den Server schickt. Response-Header, also was der Server zurückschickt, werden nicht angefasst. Wer Response-Header in Entwicklungsumgebungen überschreiben will, braucht ein anderes Tool.

Gilt das nur für Requests aus dem Browser, oder auch für curl und CI?

Nur für den Browser. Header Modifier setzt im Chrome-Prozess an — curl, Postman, Node.js-Skripte, CI-Runner und alle serverseitigen Aufrufe laufen an der Extension vorbei. Wer Nicht-Browser-Clients testen will, muss den Header dort direkt setzen.

Wie grenze ich eine Regel so ein, dass sie nicht in Produktion greift?

Im URL-Muster-Feld eine spezifische Staging-Domain eingeben, z.B. https://api.staging.example.com/*. Dann trifft die Regel nur Anfragen an genau diese Domain. Zusätzlich hilft der Master-Switch in Header Modifier: ein Klick deaktiviert alle Regeln auf einmal, ohne sie zu löschen.

Warum Chrome manche Request-Header von Erweiterungen ignoriert (2026)

Du legst eine Regel in Header Modifier an. URL-Muster stimmt, Header-Name stimmt, Wert eingetragen, Regel aktiv. Seite laden — im Network-Tab ist der Header nicht zu sehen. Keine Fehlermeldung. Keine Warnung. Einfach weg.

Das passiert bei geschützten Headern, und es ist der häufigste Grund, warum Entwickler denken, die Extension funktioniert nicht.

Was declarativeNetRequest darf und was nicht

Seit Manifest V3 läuft die Header-Manipulation in Chrome über die declarativeNetRequest-API. Chrome selbst wendet die Regeln an — die Extension sieht den Request nicht mal direkt. Das ist aus Datenschutzgründen so gebaut, und es funktioniert gut für die meisten Anwendungsfälle.

Aber Chrome hat eine Liste von Headern, die Extensions nicht anfassen dürfen. Trifft eine Regel einen dieser Header, wird sie lautlos verworfen. Keine Fehlermeldung in der Extension, kein Eintrag in der Konsole, nichts in chrome://extensions. Der Header taucht einfach nicht im Request auf.

Das ist kein Bug in Header Modifier. Das ist Chrome.

Die geschützten Header

Vollständig ist diese Liste nicht öffentlich dokumentiert — Chrome entscheidet das intern und kann es mit Updates ändern. Aber folgende Header sind erfahrungsgemäß gesperrt oder eingeschränkt:

Header	Status
`Host`	Gesperrt — Chrome setzt ihn selbst
`Content-Length`	Gesperrt — wird vom Browser berechnet
`Origin`	Eingeschränkt — CORS-Mechanismus
`Cookie`	Gesperrt — wird vom Browser selbst verwaltet
`Set-Cookie`	Response-Header, betrifft Extensions sowieso nicht
`Upgrade`	Gesperrt — für WebSocket-Handling
`Authorization`	Erlaubt — hier funktioniert Header Modifier problemlos
`X-*` Custom-Header	Erlaubt — eigene Header setzen funktioniert

Authorization ist der häufigste Anwendungsfall fürs API-Testing, und der funktioniert. Custom-Header wie X-Feature-Flag oder X-Tenant-Id ebenfalls.

Wie man feststellt, ob eine Regel greift

Devtools, Network-Tab, eine Anfrage an die richtige URL ausführen, in den Request-Headers nachschauen. Steht der Header drin? Gut. Nicht drin? Entweder URL-Muster passt nicht, oder der Header ist geschützt.

Das URL-Muster ist öfter das Problem als der geschützte Header. Ein Tipp: in Header Modifier mit * als Pattern starten, schauen ob es dann geht, dann enger fassen. Viele vertippen sich beim Schema (http:// statt https://) oder vergessen den Trailing-Slash im Muster.

Was stattdessen hilft

Für geschützte Header gibt es Alternativen:

Chrome DevTools Local Overrides: Seit Chrome 117 kann man im Network-Tab Request-Header für einen Tab direkt überschreiben, ohne Extension. Das funktioniert auch für einige geschützte Header — zumindest für Testing-Zwecke im DevTools-Kontext.

Lokaler Proxy: mitmproxy oder Charles Proxy setzen sich zwischen Browser und Server und können alles modifizieren, inklusive Response-Header. Mehr Aufwand, aber vollständige Kontrolle.

Den Header am richtigen Ort setzen: Wenn du eigentlich curl oder einen CI-Runner testen willst und die Extension als Workaround nutzt — das wird nicht funktionieren. Die Extension wirkt nur auf Browser-Requests. Den Header direkt im HTTP-Client setzen ist der richtige Weg.

Der Master-Switch und Origin-Scoping

Zwei Features in Header Modifier, die das Arbeiten mit Regeln wesentlich angenehmer machen:

Origin-Scoping im URL-Muster ist keine Pflicht, aber dringend empfohlen. Eine Regel, die für https://api.example.com/* gilt, trifft nie die Produktions-API unter https://api.example.com wenn das Pattern nur Staging abdeckt. Wer das Pattern auf * lässt, riskiert unbeabsichtigte Regeln auf allen Seiten.

Master-Switch deaktiviert alle Regeln auf einmal — ein Klick. Sinnvoll wenn man nicht sicher ist, ob eine Regel ein Problem verursacht, und schnell alles ausschalten will ohne die Konfiguration zu verlieren.

Header Modifier ist kostenlos im Chrome Web Store, kein Account nötig, kein Tracking. Regeln liegen in Chrome's Sync-Storage und folgen dem angemeldeten Profil über Neustarts hinweg.

Wer hauptsächlich Authorization-Header oder Custom-X-*-Header setzt — das funktioniert zuverlässig. Wer Host oder Cookie überschreiben will, stößt an eine Grenze, die Chrome zieht, nicht die Extension.