NW.js-proxy-instellings verskil tussen Chromium- en Node-versoeke
Stel NW.js se webenjin-proxyreels apart op van die Node-biblioteke wat dieselfde lessenaartoepassing gebruik.
NW.js kan 'n DOM-beeld laai en JSON deur 'n Node-biblioteek in dieselfde venster haal. Identifiseer die oproep wat die versoek skep voordat jy 'n proxy-koppelvlak kies.
Vir die gedokumenteerde webenjin-roete:
nw.App.setProxyConfig('proxy.example:8080', '');
const route = nw.App.getProxyForURL('https://www.example.com/');
Die eerste argument is die proxyreel en die tweede die PAC-URL. Dit kies 'n vaste HTTP-eindpunt vir bestemmingskemas wanneer PAC leeg is; HTTPS gebruik sy ondersteunde tonnelroete. In 'n onafhanklike toets van 'n publieke bladsy sonder proxy-verifikasie kan 'n inskrywing uit die HTTP-proxylys daardie eindpunt vervang.
| Versoekprodusent | Beleid om na te kyk |
|---|---|
| DOM-hulpbron of blaaier-fetch | NW.js-webenjin-proxykonfigurasie |
| Node-kern-HTTP of 'n vervoer wat deur 'n pakket besit word | Die agent of die publieke proxy-koppelvlak van daardie kliënt |
getProxyForURL gee PAC-styl beleidsteks vir 'n DOM-laai terug, soos PROXY plus 'n eindpunt of DIRECT. Dit bevestig nie dat 'n voltooide versoek dit gebruik het nie.
Om process.env.http_proxy te verander, maak nie dat elke implementering die veranderlike lees nie. Merk diagnostiek met die naam van die produsent of kliënt en die uitkoms daarvan. Gebruik daardie pakket se publieke konfigurasie eerder as om node_modules-lêers te wysig wat 'n opgradering vervang. Vir Node-kern-HTTPS-oproepe wat SOCKS gebruik, is een so 'n koppelvlak 'n SOCKS-geskikte HTTPS-agent.