הגדירו את חיבור ה-API בצד Node בקובץ webpack.config.mjs באמצעות צורת מערך הפרוקסי הנוכחית:

import { HttpsProxyAgent } from 'https-proxy-agent';

export default {
  devServer: {
    proxy: [{
      context: ['/api'],
      target: 'https://service.example',
      changeOrigin: true,
      agent: new HttpsProxyAgent('http://proxy.example:8080'),
      pathRewrite: { '^/api': '' },
    }],
  },
};

המסלול הוא:

browser → webpack dev server → corporate proxy → HTTPS API

target נשאר ה-HTTPS API האמיתי. הסוכן, שההנחה היא שכבר קיים בפרויקט, מנהל משא ומתן על הנתיב דרך המתווך HTTP.

context בוחר את נתיבי הבקשה שהדפדפן רואה; pathRewrite מסיר את קידומת הפיתוח. אף אחד מהם אינו מציין את הפרוקסי הארגוני. שמרו על המיפויים האלה עבור הנתיב שה-API מצפה לו.

השתמשו בטיפול הרגיל של ה-middleware בזרימה ובתגובות כדי שדחיית ה-API וכשל התעבורה יישארו ניתנים להבחנה. ממסר שני שנכתב ביד ותמיד מחזיר 200 היה מסתיר את התוצאה הזו.

הגדרות הפרוקסי של הדפדפן ופרוקסי הורדת החבילות של npm מגדירים צרכנים אחרים. ההגדרה הזו שייכת לתהליך webpack שמבצע את קריאת ה-API החיצונית.

מאמרים קשורים