Bad gateway after re-deploy


#1

Hey there,

I have been dealing with meteor for over a year now, and I’m facing a “strange” (to me) issue the last days.

as I’m constantly updating one of projects after the last re deployment I get a 502 bad gateway error.

I haven’t changed anything to me web server setup (nginx config, etc) so it seems very strange to me.

it gets ever more complicated that when I revert to an older version of the site, it has no issues!

finally, the site is accessible by ip or domain:port

I have even setup a new webserver from scratch on digitalocean and still the same, I used mup from meteorhacks, but again the same story.

I didn’t find anything related on the web so you guys are my last resort.

Thanks

S


#2

So what has changed between the two versions of your app?


#3

so you think the code or a package can cause something like this?

I cant say I didnt cross my mind but I wanted some opinions before I go back over my commits the last week.

this was something I really wanted to avoid


#4

It’s happened to us before. What we have done to help prevent that is have two servers up and deploy to one and when (if) it successfully deploys we deploy to the second server. Our load balancer will take the 502 server out of rotation until it passes a health check.


#5

I found the solution

apparently there are some options on your nginx.conf file you can set to prevent 502 Bad Gateway which has to be placed in this order

 http {
        include                             mime.types;
        **proxy_buffers 4 256k;**
        **proxy_buffer_size 128k;**
        **proxy_busy_buffers_size 256k;**
    
        **fastcgi_buffer_size 16k;**
        **fastcgi_buffers 16 16k;**

}

if you place them randomly under the http {

its not working.

its crazy I know, I ready it somewhere a few days ago and I had a flash today and I thought I’d tried it.

I’ll try to find the article to post it as a reference.

thanks guys

S


#6

Bad gateway error points to an app problem but if it is accessible
directly, there may be a server side route handler that’s causing the
problem (guessing) or perhaps a problem with spiderable (unlikely) so at
least to be able to cross out app differences would go a long way in
pinpointing the root cause.


#7

agreed, there should be something, but I couldnt get anything on nginx logs, or website logs.
taken into account my limited to no existent linux knowledge, I’ll take that solution for now :smile:

anyway, I’m going to check the latest package additions on my app if I can find something.

thanks again


#8

if anyone is interested here’s the post


#9

Do you have any idea why and how fastcgi parameters can fix a meteor related problem?


#10

Of course I have no clue. My experience is limited in this environment.
I cannot even explain why putting these lines anywhere else under the http does not work.

All I know if that after a lot of search this is the only solution I found. Till I get a better one, or a logical explanation I planning to stick with that.


#11

Sure if it works for you, do go for it. I’m just as puzzled and that’s why I asked, hoping perhaps you’ve figured it out.


#12

unfortunately, I don’t have the knowledge and the time to try and figure it out. I do not know where to look actually.
I posted here since I couldn’t find anything related to meteor and actually, I was hoping for a meteor related solution.