Configurazione di un punto di accesso per il debug remoto del browser su Windows

In questo articolo viene spiegato come eseguire Chrome su un host Windows e fornire un punto di accesso di debug remoto tramite CDP, utilizzabile da client Linux o MCP nella rete locale. L’approccio prevede che Chrome ascolti solo su 127.0.0.1, con portproxy che lo mappa su un indirizzo LAN e il firewall che limita le origini remote.

Topologia e flusso

Il diagramma seguente mostra il flusso delle porte all’interno dell’host Windows e come i client accedono tramite indirizzo LAN.

flowchart TB
    subgraph Windows
        A[Chrome DevTools 127.0.0.1:9222] --> B[portproxy 192.168.31.2:9222]
        B --> C[Windows Firewall]
    end
    D[Linux Client] -->|CDP| B

    classDef local fill:#2c3e50,stroke:#ecf0f1,stroke-width:2px,color:#ecf0f1
    classDef proxy fill:#3498db,stroke:#2980b9,stroke-width:2px,color:#fff
    classDef firewall fill:#f39c12,stroke:#d35400,stroke-width:2px,color:#fff
    classDef client fill:#27ae60,stroke:#229954,stroke-width:2px,color:#fff

    class A local
    class B proxy
    class C firewall
    class D client

Avvio di Chrome

Si consiglia di utilizzare una directory utente separata e specificare esplicitamente l’indirizzo di debug remoto, in modo che Chrome esponga la porta di debug solo localmente. L’esempio seguente utilizza la porta 9222; regolare in base alle esigenze.

& "C:\Program Files\Google\Chrome\Application\chrome.exe" `
  --remote-debugging-address=127.0.0.1 `
  --remote-debugging-port=9222 `
  --user-data-dir="$env:TEMP\chrome-profile-mcp"

Configurazione del forwarding delle porte

Utilizzare portproxy per mappare 127.0.0.1:9222 su 192.168.31.2:9222 dell’host Windows, consentendo ai client della rete locale di accedere.

netsh interface portproxy add v4tov4 `
  listenaddress=192.168.31.2 listenport=9222 `
  connectaddress=127.0.0.1 connectport=9222 `
  protocol=tcp

Verificare che la regola sia attiva controllando la configurazione corrente del forwarding.

netsh interface portproxy show v4tov4

Configurazione del firewall

Per limitare l’esposizione, si consiglia di consentire l’accesso solo da indirizzi IP client specifici. L’esempio seguente consente connessioni da 192.168.31.162.

New-NetFirewallRule `
  -DisplayName "Allow CDP 9222 from Linux" `
  -Direction Inbound `
  -Action Allow `
  -Protocol TCP `
  -LocalPort 9222 `
  -RemoteAddress 192.168.31.162

Verifica della connessione

Quando sia l’indirizzo locale che quello LAN restituiscono /json/version, il collegamento è disponibile. Questo passaggio aiuta a identificare rapidamente se il problema è in Chrome, portproxy o il firewall.

curl http://127.0.0.1:9222/json/version
curl http://192.168.31.2:9222/json/version

Il diagramma seguente mostra il processo di forwarding delle richieste di verifica tra i componenti.

sequenceDiagram
    participant Client as Client
    participant Proxy as Portproxy
    participant Chrome as Chrome
    Client->>Proxy: HTTP /json/version
    Proxy->>Chrome: 127.0.0.1:9222
    Chrome-->>Proxy: JSON
    Proxy-->>Client: JSON

Integrazione con MCP

Dopo aver esposto la porta, MCP deve puntare all’indirizzo LAN. L’esempio seguente utilizza chrome-devtools-mcp per connettersi a 192.168.31.2:9222.

{
  "chrome-devtools": {
    "command": "npx",
    "args": [
      "-y",
      "chrome-devtools-mcp@latest",
      "--browser-url=http://192.168.31.2:9222"
    ]
  }
}

Pulizia e ripristino

Le regole portproxy sono persistenti; se non utilizzate, eliminarle per evitare esposizioni accidentali.

netsh interface portproxy delete v4tov4 listenaddress=192.168.31.2 listenport=9222 protocol=tcp

Se si cambiano porta o IP, aggiornare parametri Chrome, regole portproxy, firewall e configurazione MCP per evitare incoerenze.

La porta di debug remoto fornisce il controllo completo del browser; non esporla su Internet né tenerla attiva a lungo in produzione. Per utilizzi cross-network, preferire VPN o tunnel zero-trust, mantenendo minimi privilegi ed esposizione.

• ←Precedente
• Successivo→