Axe MCP Server Version 1.7.0 Versionshinweise

This page is not available in the language you requested. You have been redirected to the English version of the page.

Link to this page copied to clipboard

Not for use with personal data

Veröffentlichungsdatum

12. Oktober 2026

Übersicht

Dieses Release v1.7.0 fügt Unterstützung für eingeschränkte Firmennetzwerke hinzu. Wenn Ihre Organisation verlangt, dass ausgehender Datenverkehr über einen Proxy geleitet wird oder die Websites mit einer eigenen Zertifizierungsstelle (CA) signiert, können Sie den Axe MCP Server nun entsprechend konfigurieren. Wenn Sie keine von beiden verwenden, ändert sich für Sie nichts. Dieses Release erklärt außerdem Start- und Browserprobleme in einfacher Sprache.

important

Um diese Version zu erhalten:

Docker — Ziehen Sie das Image erneut: docker pull dequesystems/axe-mcp-server:latest
npm — kein separater Installationsschritt erforderlich; npx führt die neueste veröffentlichte Version aus. Siehe Auswahl einer Distribution.

Neue Funktionen

Proxy-Unterstützung

Wenn Ihr Netzwerk nur ausgehenden Verkehr über einen Proxy, wie Zscaler, zulässt, können Sie jetzt HTTPS_PROXY (oder HTTP_PROXY für einen http://-Axe-Server) einstellen und der Server sendet seinen gesamten Verkehr über diesen Proxy an den Axe-Server, einschließlich Start, API-Schlüsselprüfungen und Behebungen. Hosts, die in NO_PROXY aufgeführt sind, verbinden sich direkt. Wenn Sie keinen Proxy einstellen, verbindet sich der Server wie zuvor direkt.

{
  "env": {
    "HTTPS_PROXY": "http://proxy.example.com:3128",
    "NO_PROXY": "intranet.example.com"
  }
}

Wenn ein Proxy eingestellt ist, verwendet ihn der Browser, der Ihre Seiten scannt, ebenfalls. Listen Sie alle Intranet-Seiten, die Sie scannen, in NO_PROXY auf. Bei der npm-Distribution verbinden sich localhost und andere lokale Adressen immer direkt, sodass Scans lokaler Entwicklungsserver nicht beeinflusst werden. Bei Docker fügen Sie auch die Adresse Ihres Docker-Hosts zu NO_PROXY hinzu. Siehe Proxy-Variablen.
Der Scan-Browser kann keinen Proxy verwenden, der einen Benutzernamen und ein Passwort benötigt. Der Server protokolliert eine Warnung, wenn Sie einen solchen einrichten.
Wenn die Proxy-URL, die der Server verwendet, keine gültige http://- oder https://-Adresse ist, stoppt der Server beim Start mit einer Meldung, die die Variable benennt.

Wenn Sie OAuth 2.0 verwenden, stellen Sie auch NODE_USE_ENV_PROXY=1 ein, damit die @deque/axe-auth-CLI Sie anmeldet und Tokens über den Proxy aktualisiert. Dies erfordert Node.js 22.21 oder höher. Siehe Proxy-Variablen.

Sehen Sie Proxy-Variablen für Details.

Klarere Anleitungen für nicht vertrauenswürdige Zertifikate

Wenn ein Scan fehlschlägt, weil der Browser das Zertifikat der Seite nicht vertraut, teilt Ihnen Ihr Agent jetzt mit, wie Sie es beheben können:

Linux und Docker — Setzen Sie NODE_EXTRA_CA_CERTS auf die CA, die das Zertifikat signiert hat, und starten Sie den Server neu.
macOS — Fügen Sie die CA Ihrem Anmeldeschlüsselbund hinzu, vertrauenswürdig nur für SSL.
Windows — Fügen Sie die CA zu Ihrem Trusted Root Store des aktuellen Benutzers hinzu, vertrauenswürdig nur für SSL.

Siehe Nicht vertrauenswürdige Zertifikate für die vollständigen Schritte.

IGT-Timeouts zeigen, wo der Lauf gestoppt hat

Wenn ein Intelligenter geführter Test-Test ein Timeout erreicht, benennt der Fehler jetzt den letzten Schritt, den er erreicht hat, und wie lange es her ist, was es erleichtert, einen festgefahrenen Test zu diagnostizieren:

IGT timed out after 200000ms (last checkpoint: keyboard:tabstops:start 83s ago; last step: analyze-tabstops-ai 61s ago; last tick 2s ago)

Fehlerbehebungen

Benutzerdefinierte CA-Zertifikate funktionieren jetzt im Scan-Browser unter Linux und Docker. Vorher erreichte NODE_EXTRA_CA_CERTS nie den Browser, sodass Seiten, die von einer internen CA signiert wurden, nicht gescannt werden konnten.
Die Einstellung von NODE_EXTRA_CA_CERTS verhindert nicht mehr den Start unter macOS und Windows. Der Server startet jetzt normal und teilt Ihnen mit, welcher systemeigene Zertifikatsspeicher stattdessen verwendet werden soll.
Der Start erklärt, warum ein benutzerdefinierter Chrome nicht starten kann. Wenn AXE_CHROME_PATH auf einen Browser zeigt, der nicht starten kann, erklärt der Server jetzt, warum. Vorher wurde der Browser als fehlend gemeldet.
Fehlende Systembibliotheken werden gemeldet, wenn Sie einen benutzerdefinierten Chrome verwenden. Wenn AXE_CHROME_PATH gesetzt ist, behalten Startfehler ihre vollständige Diagnose, einschließlich des Fixes für fehlende Linux-Bibliotheken.
Konfigurationsfehler sind leserlich. Eine ungültige Einstellung produziert jetzt eine Nachricht, die die Einstellung benennt, anstatt eines rohen AssertionError-Stack-Trace.
Defekte Dokumentationslinks behoben in Servicemeldungen.