IIS 中带有反向代理的 NodeJS 无法 GET，但可以在端口 3000 上工作

Question

我有一个在端口 3000 上运行的节点应用程序和一个 IIS 反向代理，可通过 IIS 站点为该应用程序提供服务： https://travishorn.com/reverse-proxying-node-js-apps-on-windows-与-iis-acee318b6759

我的 IIS 站点设置为端口 80 并具有以下 Web.config：

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <rewrite>
            <rules>
                <rule name="ReverseProxyInboundRule1" stopProcessing="true">
                    <match url="(.*)" />
                    <action type="Rewrite" url="http://localhost:3000/{R:1}" />
                </rule>
            </rules>
        </rewrite>
    </system.webServer>
</configuration>

如果我从端口 3000 (http://localhost:3000) 运行应用程序，它会执行路由...但是，如果我通过端口 80/IIS (http://localhost) 加载站点，则会失败并显示无法获取路由错误。它可以毫无问题地加载默认公共页面和 /api-docs 处的 Swagger-UI。

我怀疑这是我的 web.config 在起作用，因为我的路由位于子目录中。我认为使用反向代理它将通过正在运行的节点应用程序执行，但想知道 Web.config 是否需要调整这些路由。

我的结构示例如下：

node_modules
routes
    api1
    api2
server.js

我的server.js如下：

// MODULES AND REQUIRES
const express = require("express");
const app = express();
const path = require('path');
const swaggerJsDoc = require("swagger-jsdoc");
const swaggerUi = require("swagger-ui-express");
const objectMapper = require('object-mapper');
const cors = require('cors');

// Require Routes
var api1 = require('./routes/api1.js')
var api2 = require('./routes/api2.js')

// PORTS AND BASIC EXPRESS APP SETTINGS
const port = process.env.PORT || 3000;

// CORS ALLOW ALL. NOTE IP RESTRICTIONS ARE IN PLACE
app.use(cors({
  origin: '*'
}));

// ignore request for FavIcon. so there is no error in browser
const ignoreFavicon = (req, res, next) => {
  if (req.originalUrl.includes('favicon.ico')) {
      res.status(204).end();
  }
  next();
};

// Configure nonFeature
app.use(ignoreFavicon);

// Root Route - Serve Static File
app.get('/', (req, res) => {
      res.sendFile(path.join(__dirname, '/public/client.html'));
});

// SWAGGER UI CONFIGURATION

// Primary Swagger Options
const options = {
  customCss: '.swagger-ui .topbar { display: none } .swagger-ui .scheme-container { display: none }'
};

// Custom Swagger Options: https://swagger.io/specification/#infoObject
const swaggerOptions = {
  swaggerDefinition: {
    info: {
      version: "2.0.0",
      title: "My App",
      description: "This page lists the available APIs within my app and allows you to test them.",
      contact: {
        name: "My Name"
      },
      servers: [{"url":"http://localhost:3000", "description": "Development server"}]
    }
  },
  // ['.routes/*.js'] Location for APIs
  apis: ["./routes/*.js"],
};

const swaggerDocs = swaggerJsDoc(swaggerOptions);
app.use("/api-docs", swaggerUi.serve, swaggerUi.setup(swaggerDocs, options));


// ROUTES
  app.use('/api1', api1)
  app.use('/api2', api2)  

// APP LISTEN WITH SSL/HTTPS
app.listen(port, () => {
  console.log(`Server listening on port ${port}`);
});

有什么想法为什么使用反向代理无法加载/查找路由吗？

更新：

根据使用 HTTP 平台处理程序的建议，我已安装它并具有以下 Web.config。注意：iisnode、带 ARR 的反向代理和 HTTP 平台处理程序都在路由上给了我相同的错误。我想知道 Node 是否未正确运行或者我需要移动我的解决方案（它当前位于 D: 驱动器上名为 MyApp 的文件夹中）：

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="httppPlatformHandler" path="*" verb="*" modules="httpPlatformHandler" resourceType="Unspecified" />
    </handlers>
    <httpPlatform stdoutLogEnabled="true" stdoutLogFile=".\node.log" startupTimeLimit="20" processPath="C:\Program Files\nodejs\node.exe" arguments=".\server.js">
            <environmentVariables>
                <environmentVariable name="PORT" value="%HTTP_PLATFORM_PORT%" />
                <environmentVariable name="NODE_ENV" value="Production" />
            </environmentVariables>
        </httpPlatform>
  </system.webServer>
</configuration>

更新2

我一直在注销，它不断更改节点运行的端口，而不是我声明的端口 3000。据我所知，它是随机端口选择的。这可以解释为什么它无法“找到”应用程序路线

Answer 1

我在你的 server.js 中看到了这个：

const port = process.env.PORT || 3000;

您使用

process.env.PORT

告诉您的应用程序通过读取环境变量来获取端口。您放置运算符 (||) 只是为了确保如果未找到 PORT 变量，则使用指定的端口 3000。

您需要检查环境变量，应用程序可能会从环境变量中获取端口号。我建议您尝试直接使用硬编码值，而不是从环境变量中动态获取它们。

如果您对其进行硬编码，您将始终侦听端口 3000，这可能只适合您，也可能不适合您，具体取决于您的要求以及运行服务器的环境的要求。