Proxy Error with Squid and Salesforce – 502 Bad Gateway

Problem Statement

When connecting to a service hosted on a platform called Digital Ocean, the service would process for a while and finally end with a 502 Bad Gateway error.

salesforce 502 bad gateway squid I ran into a tricky issue while configuring something to integrate with Salesforce. It was something I had never seen before, and interestingly enough it had answers when Googling that go back to 2012. I was banging my head off the wall and was enlightened to the root cause just recently and wanted to share.

The errors were cryptic and the specifics of my solution were that I was making an attempt to run a Node service on DigitalOcean.com, on what they call a “droplet”.

|USER_DEBUG|[1]|DEBUG|p>Your cache administrator is <a href=“mailto:?subject=CacheErrorInfo – ERR_ZERO_SIZE_OBJECT&amp;body=CacheHost: proxy-ia4.net.salesforce.com
ErrPage: ERR_ZERO_SIZE_OBJECT
Err: [none]
TimeStamp: Fri, 30 Sep 2022 07:14:53 GMTClientIP: 10.180.37.12

The body definitely was not empty on the HttpRequest.  The connections off of the platform worked.   I could run a command successfully via cURL on my local machine,  but anything Salesforce attempted was tossed out. 

curl -d '{"args": ["-u","xyz"]}' -H "Content-Type: application/json" -X POST http://fakeservice.xyz/audit > log.txt

 

Http Callout Info

Here you can see a simple HttpRequest that was used for this situation, nothing crazy with Named Credentials or anything, just a run of the mill POST.

Lucky for me this was a personal project and I didn’t have to worry about getting it Production ready, so be aware that the solution listed below is just how I resolved the blocker, without any DevOps Engineer level advice or anything.

 


 

Solution

The service that was running on DigitalOcean needed to have a reverse proxy setup (nginx) that would forward the response it was sending on port 2000 to a normal HTTP Port. The callouts URL that I was using was an ip address and port number, like http://147.2.2.32:2000 – and Salesforce didn’t like that.

You’d think it would be the lack of HTTPS or the non-domain ip address (if you were guessing reasons), but it was my false expectation that the service on port 2000 on DigitalOcean would operate via a normal HTTP Rest callout to this endpoint.

Using the Console from DigitalOceans main dashboard is starting to get into the weeds, but the nginx configuration to allow the NodeJS service to talk through back to the HTTP endpoint was a 5 min or so setup of that reverse proxy with configuration.

There is a whole other world outside of Salesforce Development that until the last year or so has not aligned very well. Some things that are no brainers to old JS developers don’t register in a SF devs mind. I’ve since learned the reasons and need of this nginx setup, but I would not have thought of that as a to-do step. That is if I am being totally honest. Makes you have a place in your heart for a non technical PM trying to anticipate technical issues…

 

Final Thoughts

I am glad to know it is resolved. It was a humbling thing to realize that there was entire levels of configuration that needed done that I wasn’t even aware existed. More proof that it is a constant learning experience with technology and I love it!

References

  • https://www.digitalocean.com/community/tutorials/how-to-install-nginx-on-ubuntu-20-04

Leave a Reply

Your email address will not be published. Required fields are marked *