NW.js-Proxy-Einstellungen unterscheiden sich bei Chromium- und Node-Anfragen
Konfigurieren Sie die Proxyregeln der NW.js-Web-Engine getrennt von den Node-Bibliotheken, die dieselbe Desktop-Anwendung nutzt.
NW.js kann im selben Fenster ein DOM-Bild laden und JSON über eine Node-Bibliothek abrufen. Bestimmen Sie den Aufruf, der die Anfrage erzeugt, bevor Sie eine Proxy-Schnittstelle wählen.
Für den dokumentierten Weg der Web-Engine:
nw.App.setProxyConfig('proxy.example:8080', '');
const route = nw.App.getProxyForURL('https://www.example.com/');
Das erste Argument ist die Proxyregel, das zweite die PAC-URL. Damit wird für Zielschemas ein fester HTTP-Endpunkt gewählt, wenn PAC leer ist; HTTPS nutzt seinen unterstützten Tunnelpfad. In einem unabhängigen Test einer öffentlichen Seite ohne Proxy-Authentifizierung kann ein Eintrag aus der HTTP-Proxy-Liste diesen Endpunkt ersetzen.
| Erzeuger der Anfrage | Zu prüfende Richtlinie |
|---|---|
| DOM-Ressource oder Browser-Fetch | Proxy-Konfiguration der NW.js-Web-Engine |
| Node-Core-HTTP oder ein paketeigener Transport | Der Agent oder die öffentliche Proxy-Schnittstelle dieses Clients |
getProxyForURL gibt Richtlinientext im PAC-Stil für ein DOM-Laden zurück, etwa PROXY plus Endpunkt oder DIRECT. Es bestätigt nicht, dass eine abgeschlossene Anfrage ihn verwendet hat.
Das Ändern von process.env.http_proxy bewirkt nicht, dass jede Implementierung die Variable liest. Kennzeichnen Sie Diagnosen mit dem Namen des Erzeugers oder Clients und dem Ergebnis. Nutzen Sie die öffentliche Konfiguration des Pakets, statt node_modules-Dateien zu patchen, die ein Upgrade ersetzt. Für HTTPS-Aufrufe des Node-Kerns über SOCKS ist eine solche Schnittstelle ein SOCKS-fähiger HTTPS-Agent.