Proksilaj agordoj de NW.js malsamas inter petoj de Chromium kaj Node
Agordu la proksilajn regulojn de la reta motoro de NW.js aparte de la Node-bibliotekoj uzataj de la sama labortabla aplikaĵo.
NW.js povas ŝargi DOM-bildon kaj akiri JSON per Node-biblioteko en la sama fenestro. Identigu la alvokon, kiu kreas la peton, antaŭ ol elekti proksilan interfacon.
Por la dokumentita vojo de la reta motoro:
nw.App.setProxyConfig('proxy.example:8080', '');
const route = nw.App.getProxyForURL('https://www.example.com/');La unua argumento estas la proksila regulo kaj la dua la PAC-adreso. Tio elektas fiksan HTTP-finpunkton por celaj skemoj kiam PAC estas malplena; HTTPS uzas sian subtenatan tunelan vojon. En sendependa testo de publika paĝo sen proksila aŭtentigo, ero el listo de HTTP-proksiloj povas anstataŭigi tiun finpunkton.
| Produktanto de la peto | Politiko por ekzameni |
|---|---|
| DOM-rimedo aŭ foliumila fetch | Proksila agordo de la reta motoro de NW.js |
| Node-kerna HTTP aŭ transporto posedata de pako | La agento aŭ publika proksila interfaco de tiu kliento |
getProxyForURL redonas politiktekston PAC-stilan por DOM-ŝarĝo, ekzemple PROXY plus finpunkto aŭ DIRECT. Ĝi ne konfirmas, ke finita peto uzis ĝin.
Ŝanĝi process.env.http_proxy ne igas ĉiun efektivigon legi la variablon. Etikedu diagnozojn per la nomo de la produktanto aŭ kliento kaj ĝia rezulto. Uzu la publikan agordon de tiu pako anstataŭ fliki node_modules-dosierojn, kiujn ĝisdatigo anstataŭigas. Por HTTPS-alvokoj de Node-kerno uzantaj SOCKS, unu tia interfaco estas SOCKS-kapabla HTTPS-agento.