I am getting this "nginx 504 gateway timeout" when accessing my website, even when low traffic, server is 1000mbit, 36GB RAM and 2(Intel Xeon 2556). All traffic going to my site comes through a proxy server (but this error occurs even when connecting directly to the server ip)
What could be the reason, and a possible solution to this?
Have you checked if the load time of your site (eg. php script) is bigger than the proxy timeout value?
Nginx simple say: "ok I've tried but not respond in time", maybe your webserver behind nginx have a service port, try to load the website with point to this port and you can understand what is the issue.
Related
I am looking for a way to implement a captive portal for the windows 10 - mobile hotspot. The idea is to redirect all devices that connect to the hotspot to a webpage.
I was able to find this article which shows how to do it in linux.
But I have been unsuccessful in finding a similar one for windows. Posts like this one proved to be dead ends.
I am okay with using a simple nginx server to give 302 redirect response to clients if needed, but prefer not to use any existing software that implements a captive portal.
UPDATE
I have succeeded in triggering a captive portal on clients (linux laptop, android device etc) using a workaround.
Whenever a device connects to the hotspot it sends a request to some predefined websites to check if the wifi connection has internet access. If it gets a 302 response it generates the captive portal window.
So I added the following entries to the hosts file on windows machine.
127.0.0.1 clients3.google.com #android
127.0.0.1 connectivitycheck.gstatic.com #android
127.0.0.1 nmcheck.gnome.org #ubuntu
These requests will then be resolved locally using the hosts file entries and sent to the nginx server which gives a 302 redirect to all http requests.
The setup I mentioned in the UPDATE above was tweaked finally to get where I wanted. I used dnschef, an open-source dns server that works perfectly as a command line client.
The steps followed.
Start windows mobile hotspot.
Go to Network adapters => Select hotspot adapter => Change IPv4 settings => set 127.0.0.1 as DNS server.
Start dnschef with --fakeip = 192.168.137.1
Start an http server on 192.168.137.1 and give 302 redirect response to all requests.
And that's it! Whenever a device connects to the hotspot, it will attempt to connect to any one of the preset websites used to determine internet connectivity. These requests will be resolved locally by dnschef to our Nginx server. The Nginx server then gives a 302 redirect which triggers captive portal on the client.
I tried a similar approach using dnscrypt-proxy which provides dedicated captive-portal support. Since, this is nothing more than dns cloaking there are several ways to achieve, that requests to certain "connection-checking" domains are directed to a local webserver.
Unlike in the accepted answer, I figured out an even easier and more flexible way by using the windows hosts file without any third-party dns proxy. Instead of associating the connection-checking domains with localhost, I mapped them with the physical wifi accespoint ip address (which is 192.168.137.1). This causes wifi clients to directly send their connection-checking requests to the webserver, that is running on the local pc and listens to all connections on port 80.
hosts file:
192.168.137.1 captive.apple.com
192.168.137.1 clients3.google.com
192.168.137.1 nmcheck.gnome.org
192.168.137.1 connectivitycheck.gstatic.com
192.168.137.1 connectivitycheck.android.com
192.168.137.1 www.msftncsi.com
192.168.137.1 dns.msftncsi.com
192.168.137.1 www.msftconnecttest.com
192.168.137.1 ipv6.msftconnecttest.com
192.168.137.1 ipv4only.arpa
This webserver (in my case asp.net core) redirects clients to a login page, unless they are already registered. In this case the webserver may answer to the calls just like the "real" servers do, that sit behind those connection-checking domains, in order not to redirect clients, that have already been logged in successfully.
I have a web page to control a thermostat on a raspberry pi, and I'm running into difficulties when trying to get websockets to work from a remote client. It seems to work fine when on LAN however. I'm obviously missing something (and likely something basic), but I can't seem to figure out what it is.
The pi's local ip is 192.168.1.134. The web page (served from apache server) has the URL http://192.168.1.134:8010/thermostat.html. The page starts up some javascript, which then tries to connect to the pi's main program using websockets via ws://192.168.1.134:9000. (the server on the pi is running libwebsockets). The websocket comes up, and it seems to work fine. I then tried to connect via a remote client (a cell phone, where wifi was turned off) from http:\\23.239.99.99:8010\thermostat.html. The html/js files load fine, but the web socket attempts to connect to uri ws:\\23.239.99.99:9000, and this fials.
As far as I can tell, the NAT seems to be configured properly:
name ext ext protocol int int ip addr interface
port port port port
start end start end
Thermostat3 8010 8010 TCP 8010 8010 192.168.1.134 eth3.1
Thermostat5 8000 8000 TCP/UDP 80 80 192.168.1.134 eth3.1
Thermostat_ws 9000 9000 TCP/UDP 9000 9000 192.168.1.134 eth3.1
I checked, and the router does not have any firewalls set up, neither does my modem. I didn't install a firewall on the pi (I checked, and there's no odd iptables rule). Does anyone know what I'm missing?
--- EDIT ---
I'm still stuck on this. I called my ISP and they assure me there are no firewalls on their servers. Is there any way to tell if port 9000 is being blocked, and by who?
Bind your apache server to 0.0.0.0 address to make it accessible from remote machines
Try this tool to determine if the port is inaccessible (use the custom port): http://www.whatsmyip.org/port-scanner/
Everything else looks fine. As a sanity check I would try putting the ws port to 8010 to see if that works. I would also recommend using a tool like Advanced Web Client to isolate networking issues.
This is interesting. I once had a similar problem. I set up a WebSocket (I was using a nodejs ws) and once I tried to access it from remote client I was not able to reach it with ws://yourip:port but instead I had to use http://yourip:port. I don't know if you have the same problem, mine was due to a proxy I was using.
I still have an advice for you how you might be able to solve your problem. I don't know how concerned you are about security but as far as I understood your idea you basically connect to your raspberry pi through a WebSocket and tell it to change the temperature.
Back when did a similar project I found it rather hard to secure my WebSocket connection. I was basically sending a password plus command through the WebSocket to my server which then checks wether the password is correct. Otherwise everyone on the internet could heat your house. Not cool...
But therefore, I had to tunnel the connection through https to prevent a middleware attack.
I quickly threw the towel and decided to go with a completely different solution. Basically I set up a nodejs express server (can easily be configured with a self signed certificate to use https or used behind a nginx/apache https server) and authenticated with username and password. When someone made a POST request to /api/thermostats?id=0 with a temperature request, the server checks if the user is authenticated and then executes a terminal command from within node.
Maybe this idea also fits your demands.
I am relatively new to the world of java. I am building a web application where I use Spring. So here's the case:
We have deployed the web app to our development server , and have it out in the open. This is how our network administrator explained it (don't really understand it but might be important for you):
55.555.55.5 is a NAT port to 77.77.77.77 ; 77.77.77.77 is an apache proxy server that makes a connection to 99.9.99.999.
We tell this server - 55.555.55.5 on http port to connect to 99.9.99.999 on port 8080 and give the client a connection on port 80 of 55.555.55.5; At the moment it is 1:1 connection...
And here is the problem:
On http://localhost:8080/myapp/ and on http://99.9.99.999:8080/myapp/ (our development server) everything works fine.
But on http://55.555.55.5:8080/myapp/ which is visible to the clients if I load the login page and right away login its ok, but if I wait like a couple of minutes on the page I get this:
HTTP Status 501 - Method email=something%40gmail.com&password=somethingGET is not implemented by this servlet for this URI
type Status report
description The server does not support the functionality needed to fulfill this request
Apache Tomcat/8.0.32
This is really strange and I don't know why it's happening?
I have set up a squid proxy on EC2, and I'm trying to use it from behind a corporate firewall. After configuring firefox to use my proxy, I tried to surf to yahoo.com. The browser seems to hang as if handling an extremely long running request. Checking the squid logs I see:
1431354246.891 11645 xxx.0.xx.xxx TCP_MISS/200 7150 CONNECT www.yahoo.com:443 username HIER_DIRECT/xx.xxx.XX.xx-
So far, I don't have a good explanation of most of these entries , but from http://wiki.squid-cache.org/SquidFaq/SquidLogs#access.log , I've found that:
MISS = The response object delivered was the network response object.
What does this mean? Is anything I can do to connect to the outside internet?
This has been asked a long time ago, but maybe someone can still use this...
This means you connected to squid and the request was made to yahoo using the TCP protocol that HTTP uses. Furthermore, the MISS means it's a cache miss, squid doesn't have this page stored.
The reason for the hanging might be caused by the response being caught somewhere along the line (corporate firewall, maybe? local firewall?) or even misconfiguration of the proxy.
For more, perhaps you should search on https://serverfault.com, for example this is a good starting point, then you can narrow down the problem: https://serverfault.com/questions/514716/whats-the-minimum-required-squid-config-to-make-a-public-proxy-server
All,
I have a web application running on tomcat on an amazon ec2 instance and I have a DNS name on godaddy which redirects to this web app on ec2 with an elastic ip.
Everything works fine when I open the port number 80 to all inbound traffic but recently I received an email from Amazon support saying Denial of Service (DoS) attacks were launched from my instance to IP(s) xxx.xx.xx.xxx via UDP port(s) 80.
How can i make the application accessible by closing port 80 to outside world?
Thanks in advance,
keran
http is over TCP. Only open TCP on 80, keep UDP on 80 closed. The webapp should work.
I have a web application running on tomcat on an amazon ec2 instance and I have a DNS name on godaddy which redirects to this web app on ec2 with an elastic ip.
A re-directs is an HTTP thing (and not very effecient, nor good for bookmarking). Do you mean your web app has an A record?
Everything works fine when I open the port number 80 to all inbound traffic
Yup, you need to open port 80 to serve traffic.
but recently I received an email from Amazon support saying Denial of Service (DoS) attacks were launched from my instance to IP(s) xxx.xx.xx.xxx via UDP port(s) 80.
There are 2 possible explanations:
1) Your software is buggy and trying to send data to their box via UDP. This isn't that likely, but is possible if you accidentally enabled/misconfigured collectd, syslogd, statsd, or some other package.
2) Your software is buggy and let a hacker take over your box. It could have been your web application, or it could have been some other service (if you have other ports open to the world).
Either way, a good system administrator could use TCPDump to figure out where the problem is.
How can i make the application accessible by closing port 80 to outside world?
You Can't. If you want to serve traffic to the world, you need an open port. Blocking port 80 TCP will not fix your problem because "incoming traffic on TCP port 80" (used for web servers) has nothing to do with "outgoing UDP port 80". If your box is sending UDP traffic, then it's a broken/misconfigured program running on your box.
That said, you can use a proxy service like CloudFlare to "hide" your servers behind their load balancers. But that won't fix your fundamental problem, which seems to be that your box insecure. If you are going to put a server on the Internet, you need to level up your security knowledge, or hire a system administrator.
If your content is "static" (i.e. not constantly changing, like a simple blog that's updated a few times per day), you should look into serving it from S3. S3 doesn't require a System Administrator, while EC2 does.