Note di rilascio di Axe MCP Server Versione 1.7.0

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

Data di rilascio

12 ottobre 2026

Panoramica

Questo rilascio v1.7.0 aggiunge il supporto per le reti aziendali ristrette. Se la vostra organizzazione richiede che il traffico in uscita passi attraverso un proxy, o firma i propri siti con la propria autorità di certificazione (CA), ora è possibile configurare Axe MCP Server per lavorare con essi. Se non usate nessuno dei due, nulla cambia per voi. Questo rilascio spiega inoltre i problemi di avvio e del browser in termini semplici.

important

Per ottenere questo rilascio:

Docker — ri-trascinare l'immagine: docker pull dequesystems/axe-mcp-server:latest
npm — non è richiesta alcuna fase di installazione separata; npx esegue l'ultima versione pubblicata. Vedi Scelta di una distribuzione.

Nuove funzionalità

Supporto Proxy

Se la vostra rete consente il traffico in uscita solo attraverso un proxy, come Zscaler, ora potete impostare HTTPS_PROXY (o HTTP_PROXY per un server axe http://) e il server invierà tutto il suo traffico al server axe attraverso quel proxy, inclusi avvio, controlli delle chiavi API e rimedio. Gli host elencati in NO_PROXY si connettono direttamente. Se non impostate un proxy, il server si connette direttamente, come prima.

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

Quando un proxy è impostato, anche il browser che esegue la scansione delle vostre pagine lo utilizza. Elencate eventuali siti intranet che eseguite in NO_PROXY. Con la distribuzione npm, localhost e altri indirizzi locali si connettono sempre direttamente, quindi le scansioni dei server di sviluppo locale non sono influenzate. Con Docker, aggiungete anche l'indirizzo del vostro host Docker a NO_PROXY. Vedi Variabili proxy.
Il browser di scansione non può utilizzare un proxy che richiede un nome utente e una password. Il server registra un avviso se ne impostate uno.
Se l'URL del proxy utilizzato dal server non è un indirizzo http:// o https:// valido, il server si arresta all'avvio con un messaggio che nomina la variabile.

Se usate OAuth 2.0, impostate anche NODE_USE_ENV_PROXY=1 in modo che la CLI @deque/axe-auth vi autentichi e aggiorni i token tramite proxy. Questo richiede Node.js 22.21 o superiore. Vedi Variabili proxy.

Vedi Variabili proxy per i dettagli.

Guida più chiara per certificati non attendibili

Quando una scansione fallisce perché il browser non si fida del certificato della pagina, il vostro agente ora vi dice come risolvere il problema:

Linux e Docker — impostare NODE_EXTRA_CA_CERTS come CA che ha firmato il certificato, quindi riavviare il server.
macOS — aggiungere la CA al proprio portachiavi di login, affidabile solo per SSL.
Windows — aggiungere la CA al proprio store di radici affidabili dell'utente corrente, affidabile solo per SSL.

Vedi Certificati non attendibili per i passaggi completi.

Timeout IGT indicano dove si è fermata l'esecuzione

Quando un Test guidato intelligente va in timeout, l'errore nomina ora l'ultimo passo raggiunto e quanto tempo fa, il che rende molto più facile diagnosticare un test bloccato:

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

Correzioni di bug

I certificati CA personalizzati ora funzionano nel browser di scansione su Linux e Docker. Prima, NODE_EXTRA_CA_CERTS non arrivava mai al browser, quindi le pagine firmate da una CA interna non potevano essere scansionate.
Impostare NODE_EXTRA_CA_CERTS non ferma più l'avvio su macOS e Windows. Il server ora si avvia normalmente e vi dice quale store di certificati di sistema utilizzare invece.
L'avvio spiega perché un Chrome personalizzato non può essere avviato. Se AXE_CHROME_PATH punta a un browser che non può avviarsi, il server ora spiega perché. In precedenza, indicava il browser come mancante.
Le librerie di sistema mancanti vengono segnalate quando si utilizza un Chrome personalizzato. Quando AXE_CHROME_PATH è impostato, gli errori di avvio mantengono la loro diagnostica completa, incluso il rimedio per le librerie Linux mancanti.
Gli errori di configurazione sono leggibili. Un'impostazione non valida produce ora un messaggio che nomina l'impostazione, invece di un grezzo AssertionError stack trace.
Correzione di collegamenti documentazione interrotti nei messaggi del server.