部署Azure时Node.js Express+IISnode报HRESULT:0x6d HTTP500子状态1013解决

Hey there! It's totally normal to hit environment-specific snags when moving from local/self-hosted VMs to Azure, especially when you're new to Node.js/Express + iisnode. Let's break down that HRESULT: 0x6d (HTTP 500.1013) error and walk through fixes step by step:

1. 先排查IISnode进程启动与权限问题 #

This is the most common culprit for 500.1013 errors in Azure:

• Check App Pool Identity: Your self-hosted VM might use Local System for the app pool, but Azure defaults to ApplicationPoolIdentity which has stricter permissions. Test switching the app pool identity to Local System (you can lock down permissions later) then restart IIS and the app pool.
• Verify Log Directory Permissions: Your web.config specifies logDirectory="C:\inetpub\logs\abc\iisnode"—make sure the app pool's identity user has read/write access to this folder. If iisnode can't write logs, it might fail to start the Node process entirely.
• Check IISnode Logs: If the log folder has proper permissions, look for server.js-related logs in that directory. They'll have way more specific details than the generic 500 error (like Node process crash reasons or missing dependencies).

2. Validate Node.js Path & Dependencies #

• Confirm Node.js Installation: Double-check that C:\Program Files\nodejs\node.exe exists on your Azure server, and that its version matches what you used locally/on your self-hosted VM (version mismatches can break dependency compatibility).
• Ensure Complete node_modules: Sometimes deployment tools skip node_modules or fail to install dependencies properly. SSH into your Azure server, navigate to your project folder, and run npm install manually to make sure all packages are present and compatible.

3. Fix Nodemailer Network & Authentication Issues #

Since you're using Gmail's SMTP, Azure's environment might block or restrict this:

• Check Azure NSG Outbound Rules: Make sure your Azure Server's Network Security Group (NSG) allows outbound TCP traffic on port 465 (required for Gmail's secure SMTP). Azure defaults restrict some ports, so you'll need to add an explicit rule for this.
• Verify Gmail SMTP Settings: If you're using a regular password, ensure you've enabled less secure app access (or better yet, use an App Password if you have 2FA enabled on your Gmail account). Also check your Google Account Security page to make sure Azure's IP isn't flagged as a suspicious login.
• Test Nodemailer Directly: Run a standalone Node script on Azure to rule out IISnode interference:

  const nodemailer = require('nodemailer');
  async function testMail() {
    let transporter = nodemailer.createTransport({
      host: "smtp.gmail.com",
      port: 465,
      secure: true,
      auth: {
        user: "aasome.fakemailzz@gmail.com",
        pass: "somefakepass"
      }
    });
    let info = await transporter.sendMail({
      from: "contact@somefakedomain.io",
      to: "fakename@somefakedomain.com",
      subject: "Test from Azure",
      text: "Test mail successful!"
    });
    console.log(info);
  }
  testMail().catch(console.error);
  

  If this fails, the issue is with Nodemailer/network settings, not IISnode. If it works, move on to IIS configuration checks.

4. Tweak IIS Configuration Details #

• Fix Rewrite Rules: Your current rule <match url="api/*" /> might not catch your actual API path (/abc_backend/api/general/contacting). Update it to match your route structure:

  <rule name="abc_test" stopProcessing="true">
    <match url="abc_backend/api/(.*)" />
    <action type="Rewrite" url="server.js" />
  </rule>
  

• Enable Detailed Error Messages: Uncomment the <httpErrors existingResponse="PassThrough"> line in web.config—this will expose the full error stack instead of the generic 500 message, making debugging way easier.
• Double-Check WebDAV: You've removed the WebDAVModule, which is good (it often blocks POST requests), but confirm in IIS Manager that WebDAV is fully disabled for your site.

5. Test Node Process Manually #

• Run Server Directly: On your Azure server, navigate to your project folder and run node server.js. Use Postman or curl to send a POST request to the contact endpoint. If this works, the problem is with iisnode configuration/permissions. If it fails, you've got a code or dependency issue to fix first.
• Check IIS Logs: Look for detailed request logs in C:\inetpub\logs\LogFiles\W3SVCxxxx—these will include specific details about the 500.1013 error that aren't visible in the browser.

Work through these steps one by one, and you'll narrow down the root cause in no time. It's all about eliminating variables between your working environments and Azure!

内容的提问来源于stack exchange，提问作者vic