I'm building an app where angular front-end is on s3 as static website and Sails (0.10.3) API inside dokku with Node 0.11.13 and SSL on EC2. If file is larger than about 4mb I got error "No 'Access-Control-Allow-Origin' header is present on the requested resource." OPTIONS request is hitting my API and I can catch it in customMiddleware but the POST with data is not reaching that far. On front-end side I'm using angularjs-file-upload.
If I turn off SSL then it works without any problems but I would prefer to keep it on.
One more thing you can try, if it's Nginx that's causing issues. Look into your error log file. Generally its /var/log/nginx/error.log
In that if you see this line
*133774 client intended to send too large body: 3141911 bytes
It means the issue is of the size and you might wanna fix it.
The way you do it is in your nginx.conf in the HTTP context paste this anywhere.
client_max_body_size 50M;
This will allow you to increase your body size to 50M.
Hence fixing the issue
I went up the chain app itself -> dokku -> SSL and the problem was even higher, in nginx.
nginx.conf required one line more:
proxy_read_timeout 1200s;
I had a similar solution and I solved it with the help of this. It's because of the client_max_body_size configuration variable that Nginx has.
1.Go to nginx configuration setting file:
sudo nano /etc/nginx/nginx.conf
2.Change in nginx.conf file:
http {
clientmaxbody_size 100m;
}
3.Restart Your Nginx:
sudo service nginx restart
or
service nginx reload
for my MEAN Stack (node & Expreess js) application it worked.
Hoping for your case too !
Another EXPRESS code if 1,2 & 3 point won't work for you
const express = require('express');
const cors = require('cors');
const app = express();
app.use(cors());
Below link for reference full detail explanation:
https://www.digitalocean.com/community/questions/how-to-edit-nginx-setting-for-big-file-upload
Related
Trying to setup a staging environment on Amazon LINUX EC2 instance and migrate from Heroku.
My repository has two folders:
Web
API
Our frontend and backend are running on the same port in deployment
In dev, these are run on separate ports and all requests from WEB and proxied to API
(for ex. WEB runs on PORT 3000 and API runs on PORT 3001. Have a proxy set up in the package.json file in WEB/)
Currently the application deployment works like this:
Build Web/ for distribution
Copy build/ to API folder
Deploy to Heroku with web npm start
In prod, we only deploy API folder with the WEB build/
Current nginx.conf looks like this
Commented out all other attempts
Also using PM2 to run the thread like so
$ sudo pm2 bin/www
Current thread running like so:
pm2 log
This is running on PORT 3000 on the EC2 instance
Going to the public IPv4 DNS for instance brings me to the login, which it's getting from the /build folder but none of the login methods (or any API calls) are working.
502 response example
I have tried a lot of different configurations. Set up the proxy_pass to port 3000 since thats where the Node process is running.
The only response codes I get are 405 Not Allowed and 502 Bad Gateway
Please let me know if there is any other information I can provide to find the solution.
It looks like you don't have an upstream block in your configuration. Looks like you're trying to use proxy-pass to send to a named server and port instead of a defined upstream. There's is an example on this page that shows how you define the upstream and then send traffic to it. https://nginx.org/en/docs/http/ngx_http_upstream_module.html
server backend1.example.com weight=5;
server backend2.example.com:8080;
server unix:/tmp/backend3;
server backup1.example.com:8080 backup;
server backup2.example.com:8080 backup;
}
server {
location / {
proxy_pass http://backend;
}
}````
Turns out there was an issue with express-sessions being stored in Postgres.
This led me to retest the connection strings and I found out that I kept receiving the following error:
connect ECONNREFUSED 127.0.0.1:5432
I did have a .env file holding the env variables and they were not being read by pm2.
So I added this line to app.js:
const path = require("path");
require('dotenv').config({ path: path.join(__dirname, '.env') });
then restarted the app with pm2 with the following command:
$ pm2 restart /bin/www --update-env
Trying to get Simple Express Application up using NameCheap Shared Hosting.
I have set up my Node JS application as Described here NodeJS NameCheap Docs
Current Setup:
Application Root: url.com
Application URL: url.com
Application Startup File: server.js
I have ran NPM Install using the button provided
I have tried loading the URL http://url.com/hello Expecting Hello World to displayed in the Page.
var express = require("express");
var app = express();
const port = 3001;
app.set("port", port);
app.get("/hello", function(req, res) {
res.send("hello world");
});
app.listen(app.get("port"), () =>
console.log("Started listening on %s", app.get("port"))
);
The results I am getting when navigating to http://url.com/hello:
Not Found
The requested URL /index.php was not found on this server.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
Namecheap only tells you how to configure the nodejs app however their hosting is based on cPanel which requires you configure the webserver (apache generally). Once you get an application running there’s a special button to register it for the apache configuration aka let it run from your domain. I don’t know the steps by heart but you should ask NC support to direct you to their documentation for configuring apache to run a nodejs app you configured.
If they do not link an article from their knowledge base use this link: https://confluence1.cpanel.net/plugins/servlet/mobile?contentId=17190639#content/view/17190639
Basically what you need now is to configure cPanel or ssh into your server and test your app locally. There’s a number of things that could cause your issues like incorrect apache configuration (your default port 80 is looking for php app), port not open/firewalled, application not registered - and all of this is cPanel specific.
To make sure you are reading the correct document check in namecheap cpanel for the docs button and review all the above. It should be obvious what needs configured - your nodejs code is probably not the cause here
In my case, it was the problem with .htaccess file. Adding the following rules in my .htaccess file present in the website's public directory helped me:
# CLOUDLINUX PASSENGER CONFIGURATION BEGIN
PassengerAppRoot "/home/<user>/<your_nodejs_app_folder>"
PassengerBaseURI "/."
PassengerNodejs "/home/<user>/nodevenv/<nodejs_app>/<version>/bin/node"
PassengerAppType node
PassengerStartupFile <startup_script>.js
# CLOUDLINUX PASSENGER CONFIGURATION END
Make the required changes in the above rules before pasting them in your .htaccess file. Also, just in case, make sure the port you are using is open, via customer support.
I have my backend app deployed on GAE. Inside it, I am having an API which will upload a file to a GCS bucket.
Recently I tried uploading a file of more than 50mb size and got 413 Request entity too large
Did some research and found out that the issue is with ngnix. The API will give 413 for any file > 32Mb.
Found one solution where it was mentioned to include a ngnix.conf file and add client_max_body_size 80M in it.
I did so but still getting the same error.
This is my ngnix-app.conf file
server{
location / {
client_max_body_size 80m;
client_body_buffer_size 512k;
}
}
Anything obvious that I am missing out here?
You can change your request buffer size in your Node.Js application using
app.use(bodyParser.json({limit: '50mb'}));
app.use(bodyParser.urlencoded({limit: '50mb', extended: true}));
Also you can increase your request in nginx configuration
server{
location / {
client_max_body_size xxm;
client_body_buffer_size xxm;
}
}
Just Modify NGINX Configuration File
sudo nano /etc/nginx/nginx.conf
Search for this variable: client_max_body_size. If you find it, then just increase the value to 100M. If you can't find this then just add
this line inside HTTP.
client_max_body_size 100M;
To apply changes just restart ngnix
sudo service nginx restart
See screenshot for better understand
I am hosting the web app on Google Cloud Platform with App Engine and I am using ExpressJS and MongoDB, which is hosted on mLab.
Everything worked well until 1/1/2017. I had vm:true before and now was forced to change the env to flex. Now I am getting 502 bad gateway error with nginx. App engine doesn't allow us to change the nginx config file.
I had tried the suggestion from this post: Google App Engine 502 (Bad Gateway) with NodeJS but still doesn't work.
For some reason, I have another app with exactly the same setting on app engine and it works perfectly.
Any suggestion will be greatly appreciated. Thank you.
app should always listen to port 8080, google forwards all request from 80 to 8080
https://cloud.google.com/appengine/docs/flexible/custom-runtimes/build#listen_to_port_8080
check out the logs for any deployment errors
$ gcloud app logs read
I have came across a similar issue with the code provided by this tutorial (https://cloud.google.com/nodejs/getting-started/authenticate-users)
And found there was a missing dependency. I fixed the missing dependency and the app is deployed and working fine.
Details into the issue: https://github.com/GoogleCloudPlatform/nodejs-getting-started/issues/106
I had the same problem with Express. What solved it for me was to not provide an IP address for the app.
So my old code would be:
var ip = "127.0.0.1";
var port = "8080";
var server = http.createServer(app);
server.listen(port, ip);
This would result in a 502 in app engine.
Removing the ip was the solution for me.
server.listen(port);
Set the host to 0.0.0.0
Port 8080 is set by default by the engine. In fact, you are not able to define the environment var PORT as it is reserved.
Run the next command (as mentioned by #sravan )
gcloud app logs read tail
and make sure it looks like this,
[Sun May 27 2018 10:32:44 GMT+0000 (UTC)] serving app on 0.0.0.0:8080
Cheers
Google App Engine uses an nginx front to load balance all requests for node.js apps. With nginx acting as a forward proxy, this error usually happens when the request the user is making in the browser is reaching nginx (you see the unstyled 502 bad gateway error page) but the nginx server is not able to correctly forward the request to your node app. There could be many issues why this is happening but here are some common ones:
By default, App Engine assumes your node app is running on 8080. nginx itself will run on 80 and forward the request to 8080. Check if your app's port number is 8080.
You app may have a hostname defined like a domain something.appspot.com or an IP 127.18.21.21 or the like. Remove any hostnames from your server.listen or config.json or vhost wherever. App Engine will take care of domains, IPs etc so you dont have to.
Your app may be crashing before its sending a response to nginx. Check the logs of both nginx AND your node app.
To check logs / find out what is going on use this guide https://cloud.google.com/appengine/docs/flexible/nodejs/debugging-an-instance#connecting_to_the_instance to SSH directly inside the VM behind app engine. There will be one docker process with nginx where you can see the nginx error log and one docker image with your node app to check your node app's error message.
I'm just wondering, based on the activity in this question and the timestamps, why hasn't Google updated its documentation to cover this issue!!! ???
Please take care of http also, while deploying, it should be http server not https
var server;
if (process.env.NODE_ENV == "dev") {
server = https.createServer(httpsOptions, app);
} else {
server = http.createServer(app);
}
A 502 is not necessarily an error with nginx itself, it can most often happen when the nginx proxy cannot talk to your app container (usually because your app failed to start). If you get a 502 after migrating to 'env: flex' this is most likely due to some code changes needed in your app as mentioned in Upgrading to the Latest App Engine Flexible Environment Release.
Checking your application logs for errors from NPM will also help to diagnose the exact reason for the failed startup.
Create a server and then check with a ternary condition if current environment is production or not, assign port '80' if current environment is development else assign process.env.NODE.ENV.
const app = require('express')();
const server = require('http').Server(app);
const port = process.env.NODE_ENV === 'production' ? process.env.PORT :'80';
server.listen(port, ()=> {
console.log('listening on port number *:' + server.address().port);
});
In my case, I had the same error due to google app engine update which trigged auto re-deployment of my React SPA to the google cloud vm. Then it leads to a build fail in the process because of incompatibility of runtime which is node 16.x.x. Compatible runtime was node 14.19.0. I had to specify node version in my package.json file and do the deployment again to fix 502 Bad Gateway error.
{
"engines": {
"node": "14.19.0"
}
}
Also refer:
https://cloud.google.com/appengine/docs/nodejs
https://cloud.google.com/appengine/docs/flexible/nodejs/runtime
Hope this helps with someone having this issue with React SPAs.
Alright, so I setup a node.js server quite a while ago on a AWS EC2 micro server. I was completely new to it and followed various tutorials to get it up and running. It used nginx as a reverse proxy (I believe) and the server was listening on port 8124.
Now, the instance got restarted and I can't for the life of me get access to my server back. I can ssh to it. I can start the server. I can send POST/PUT requests to it through my local command line, but my web browser gives me the 404 nginx page.
This is driving me up the wall - where in the browser/nginx/nodejs chain are things breaking down?
Please help - I'm horribly new at this at it must be a single line somewhere that's broken. I just don't know enough to find it.
My /etc/nginx/sites-enables/default file simply contains
location / {
proxy_pass http://127.0.0.1:8124/;
}
Okay I figured it out. I had to go directly into /etc/nginx/nginx.conf and in the server that was there
location / {
root /usr/share/nginx/html;
index index.html index.htm;
}
I added the line
proxy_pass http://127.0.0.1:8124/;
Oh thank god. That was going to kill me.