Users are getting the following error when trying to access an OAG application:

502 Bad Gateway

The OAG logs specifically show an error such as the following:

2025-04-18T15:45:21.000-07:00 oag.testdomain.com oag.test.domain.com 5qx6V5WWL: 2025/04/18 15:45:21 [error] 929870#0: *26548335 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 10.132.65.68, server: oagldapapp.testdomain.com, request: "POST /5qx6V5WWL/module.php/saml/sp/saml2-acs.php/PgAp14RRQ HTTP/1.1", upstream: "fastcgi://unix:/var/run/php-fpm/php-fpm.sock:", host: "oagldapapp.testdomain.com", referrer: "https://testdomain.okta.com/"

NOTE:

• The error is specifically occurring on the POST request to the SAML module of the OAG application (in the format "<shortName>/module.php/saml/sp/saml2-acs.php/<entityId>").
• The error references the following as the upstream: "fastcgi://unix:/var/run/php-fpm/php-fpm.sock".
• The OAG application in question is configured with attributes that pull from a Data Store, such as LDAP: Integrate Data Stores.

• Okta Access Gateway (OAG)
• Application configured with attributes that pull from Data Stores

In this case, the issue was that the application was configured to pull attributes from the LDAP Data Store, and some of the Worker Nodes were failing to connect to the LDAP Data Store due to an environmental network issue.

The LDAP Data Stores did show as valid in the Admin UI, but this was because this page only shows connectivity from the perspective of the Admin Node, and in this case, the Admin Node maintained good connectivity to the LDAP Data Store.

On the Worker Nodes, the following error was seen in the Monitor logs (although not necessarily logged at the same time as the actual login failure), indicating that the LDAP Data Stores were in a failed status on those nodes:

2025-03-31T03:29:39.226-07:00 oag.test.domain.com OAG_MONITOR MONITOR STORE ALERT VALIDATE [NAME="LDAP Test Store 1" STATUS="failed"] Failed to connect: 

1. If the attributes that pull from the LDAP Data Store are not actually required, consider deleting them from the application configuration to remove the dependency on the Data Store.
   •  NOTE: Simply toggling the attribute to Do not Send is not sufficient.
2. If the attributes from the LDAP Data Store are necessary, resolve the underlying connectivity issue to the LDAP Data Store (may be a network or credentials issue).