How-tos
Node.js 502 Bad Gateway Issues and How To Resolve Them
April 5, 2019 | Written by: Gabriele de Capoa and Khalid Abbas
Categorized: How-tos | Open Source
Share this post:
Recent Node.js 502 bad gateway issues
In December of 2018, many Node.js users noticed that their applications randomly returned an HTTP status code 502 “Bad Gateway” error. On the IBM Cloud, the affected applications are deployed as Cloud Foundry applications or as Docker containers in Kubernetes clusters.
The Node.js community immediately noticed the issue and recognized it as a regression bug that will affect different LTS runtime versions (6.14.x and 6.15.x, 8.14.x, and 10.14.x). Further information about this bug can be found in this Github issue on Node.js source code.
Immediately the community started to fix this bug. Before the end of 2018, the community released new minor versions which contain the fix. In particular, the minor versions released are 6.16.x, 8.15.x, and 10.15.x.
Steps to take to resolve the issue
If you have been affected by this issue, you can easily resolve it by forcing your application to use a higher Node.js runtime version from your package.json
file.
Here is an example of how to do that:
{ "name": "get-started-node", "main": "server.js", "description": "An introduction to developing Node.js apps on the Bluemix platform", "version": "0.1.1", "private": false, "engines": { "node": "^7.10.0" }, "scripts": { "start": "node server.js" }, "repository": { "type": "git", "url": "https://github.com/IBM-Bluemix/get-started-node" }, "dependencies": { "@dynatrace/oneagent": "^1.137.152-1.0.0", "body-parser": "^1.17.x", "cfenv": "^1.0.x", "cloudant": "1.9.x", "dotenv": "^4.0.0", "express": "^4.15.x", "npm": "^6.4.1", "semver": "^5.6.0" }, "author": "IBM Corp", "license": "Apache-2.0" }
As you can see, the package.json
file contains pretty much all of the dependencies that you need for your app. The most important section is:
"engines": { "node": "^7.10.0" }
As you know, this section specifies which Node.js runtime version is to be used to run the application. Updating the value of this key with a “good” runtime version (e.g., 6.16.x, 8.15.x, or 10.15.x) will resolve this kind of issues.
If you are pushing your application in IBM Cloud on Cloud Foundry (using cf push APP_NAME
), you could try to use -b
option for setting an older buildpack version, but without changing the Node.js runtime version in package.json
, you could still face the issue.
If you are deploying your application as a Docker container inside an IBM Cloud Kubernetes Service cluster and you are using the official Node.js images, you will not face this issue since you will automatically use always the last minor version for the major version chosen.

Software Engineer - IBM Cloud Advanced Customer Support

IBM Cloud Support Engineer
Seamless Integration: Istio and External Services
By defining our own MCP server, we allow users to move to the Istio service mesh without any code and deployment model changes. This means we can easily use Istio to control, observe, connect, and secure services running outside Kubernetes clusters.
Help Shape the Future of Cloud Foundry
Are you a Cloud Foundry user? If so, here's your opportunity to influence the future of Cloud Foundry with the 2019 user survey.
Java Licensing Has Changed, but There’s Good News
If you downloaded your Java SE binary from Oracle.com and are using it for commercial purposes, you have probably heard that they’ve introduced a new pricing model. Fortunately, the Eclipse OpenJ9 project delivers a no-cost JVM on AdoptOpenJDK, even for commercial use. As an added bonus, OpenJ9 is faster and leaner than other JVMs.