Skip to content
English
Customer portal
Go to neeve.ai
  • There are no suggestions because the search field is empty.

Troubleshooting & Resolving 502 Bad Gateway Errors

This document provides step-by-step instructions to diagnose and resolve 502 Bad Gateway errors encountered on web applications when accessing through remote access portal

 1. What Is a 502 Bad Gateway Error?

A 502 Bad Gateway error occurs when a gateway or intermediary server, such as a reverse proxy or load balancer, receives an invalid response from the application server or endpoint it is trying to reach.

In simple terms, the Remote Access Portal receives your request but cannot communicate successfully with the application or device/endpoint.

 Key Takeaway: A 502 Bad Gateway error occurs when the Remote Access Portal cannot obtain a valid response from the application or device/endpoint. This may be caused by an application service issue, a closed port, firewall restrictions, or a connectivity problem between the portal and the destination device. 

2. Most common Causes
  • Device/endpoint Unreachable: The device is powered off, disconnected from the network, or affected by routing or connectivity issues.
  • Application Service Not Running: The web application service is stopped, crashed, or unresponsive.
  • Required Port Closed: The application is not listening on the expected TCP port, such as port 80 (HTTP), 443 (HTTPS), or 8080.
  • Firewall Blocking Traffic: The local firewall or network firewall is blocking connections to the required port.

3. Quick Diagnostic Checklist

Diagnostic Step

Tool / Command

Expected Result

Action if Failed

1. Host Ping Test

ping <Target_IP>

4 replies received

Verify server power status and network physical connectivity.

2. Port Reachability Scan

nmap -p <Port> <Target_IP>

State: open

If closed: Start the application service.

If filtered: Adjust firewall rules.

3. Local Service Check

netstat -an | findstr :<Port>

State: LISTENING

Restart or start the local backend web application service.

4. Step-by-Step Resolution Guide

Step 1: Verify Device/Endpoint Power & IP Connectivity

Ensure the device/endpoint is turned on and connected to the local network.

  1. Open Command Prompt or Terminal on a local jump box or server on the same subnet.
  2. Run a ping test against the target machine IP address:

ping 192.168.2.1

If you receive "Request timed out" or "Destination host unreachable," power on the machine or check local network cabling.

Step 2: Check Application Service Status

Log in to the Device/Endpoint locally or via direct access to verify the application process is running.

  • Windows Server: Open services.msc, locate your web application service (e.g., IIS, World Wide Web Publishing Service, or custom node app), and verify the Status is set to Running. If stopped, right-click and select Start.
  • Linux Server: Check service status via systemctl:

           Command: systemctl status your-web-service

Step 3: Verify Listening Port State (Nmap / Netstat)

Determine whether the application is actively listening on the target port (e.g., Port 80).

  1. Run an Nmap scan from the any device from local network:

nmap -p 80 192.168.2.1

  1. Review the reported port state:
  • OPEN: Port is active and listening. Proceed to Step 4.
  • CLOSED: Network route is fine, but no process is listening on Port 80. Restart the web application service.
  • FILTERED: Network or host firewall is dropping packets. Proceed to Step 4.

Step 4: Configure Host & Network Firewall Rules

Ensure inbound connections on the required HTTP/HTTPS port are permitted on both local and network firewalls.

  • Windows Defender Firewall (Inbound Rule):
  1. Open Windows Defender Firewall with Advanced Security.
  2. Click Inbound Rules > New Rule...
  3. Select Port > Choose TCP and specify Specific local ports: 80 (or your application port).
  4. Select Allow the connection and apply rule to Domain, Private, and Public profiles.
  5. Name the rule (e.g., "Allow Web Application Port 80 Inbound") and click Finish.
  • Network Firewall: Verify perimeter/hardware firewall rules allow TCP traffic on Port 80/443 between the gateway IP and the target IP.
5. Verification & Final Testing
Once the application service is running and firewall ports are open:
  1. Re-run the Nmap scan to verify the port state shows as open.
  2. Access the web link directly in a web browser or via curl:

curl -I http://<Target_IP_or_URL>

A successful test should return an HTTP status code 200 OK or 301/302 Redirect instead of 502 Bad Gateway.