Websites herunterladen, die Envoy nutzen

Über Envoy

Envoy entstand, um ein Problem im Serverbestand eines einzelnen Unternehmens zu lösen: zu viele Dienste, die sich gegenseitig über ein Netzwerk aufriefen, in das niemand hineinsehen konnte. Die Software, die wir in der Kategorie Reverse proxies führen, ist ein Proxy auf Anwendungsebene, der Diensten vorgeschaltet ist oder zwischen ihnen steht und Lastverteilung, Wiederholungsversuche, Circuit Breaking, Traffic-Routing und TLS-Terminierung übernimmt. Für viele Service-Mesh-, Ingress- und API-Gateway-Produkte ist Envoy die Komponente, die als Datenebene läuft.

Niemand, der eine Website veröffentlicht, wählt Envoy so aus, wie man ein CMS auswählt. Die Entscheidung trifft ein Plattform-Team, oder der Proxy kommt als Unterbau eines verwalteten Gateways, eines API-Produkts oder einer Hosting-Plattform mit, die aus ganz anderen Gründen gekauft wurde. Wenn wir den Proxy auf einer Domain erkennen, ist das deshalb eher ein organisatorisches als ein technisches Signal. Hinter einer solchen Domain stehen sehr wahrscheinlich ein containerorchestriertes Backend, ein Team, das das Request-Routing als eigene Disziplin verantwortet, und ein Infrastrukturbudget, das ein Shared-Hosting-Kunde nicht hat.

Das Entwicklerteam, das den Proxy geschrieben hat, übergab das Projekt an die Cloud Native Computing Foundation, die es seitdem betreut. Die Lizenz Apache 2.0 und die Implementierung in C++ erlauben es Anbietern, die Software ohne Rückfrage einzubetten und weiterzuverkaufen, was zu einem großen Teil erklärt, wie sie sich verbreitet hat. Der Proxy erschien 2016 und wurde so schnell zur gängigen Lösung für die Steuerung des Traffics zwischen Diensten, dass sein Name heute in Produkten auftaucht, die ihn in ihrem Marketing nie erwähnen.

Stand Oktober 2026 erkennen wir Envoy auf 87.676 Websites. 49.595 davon verorten wir in den USA, und unter den Domainendungen ist .com besonders stark vertreten. Eine Häufung in einem Land spiegelt wider, wo die Cloud-Native-Entwicklung ihren Schwerpunkt hat und wo die Anbieter, die den Proxy einbetten, am stärksten verkaufen, und wahrscheinlich auch, wo Betreiber sich am wenigsten die Mühe machen, identifizierende Response-Header zu entfernen.

Den letzten Punkt sollte man klar aussprechen, statt ihn zu verstecken. Die Erkennung beruht hier auf Schlussfolgerungen. Wir lesen Signaturen in Response-Headern und Fingerabdrücke von Fehlerseiten, die der Proxy standardmäßig ausgibt, und jeder Betreiber kann sie mit einer einzigen Konfigurationszeile umbenennen oder entfernen. Bei Websites hinter einem Content Delivery Network, das die Verbindung zuerst terminiert, gibt sich der Proxy unter Umständen überhaupt nicht zu erkennen. Die erfasste Zahl ist eine Untergrenze. Ein Treffer zeigt, dass der Proxy geantwortet hat, aber nicht, ob das Team ihn selbst betreibt oder mit einem verwalteten Produkt übernommen hat. Diese Unterscheidung können wir von außen nicht treffen.

Für Anbieter aus Infrastruktur, Observability und Sicherheit liegt der Wert der Liste darin, dass sie Organisationen danach identifiziert, wie sie arbeiten, und nicht danach, was sie veröffentlichen. Eine Einzelabfrage bestätigt einen Header auf einer Domain. Mit dem gesamten Bestand können Sie abschätzen, wie viele Plattform-Teams als Kunden infrage kommen, den Proxy mit den Clouds und Frameworks in Beziehung setzen, neben denen er auftaucht, und verfolgen, wie diese Gruppe zwischen den Aktualisierungen wächst oder sich verschiebt. Genau diese Frage stellt sich jeder, der im Markt für Cloud-Native-Infrastruktur verkauft.