I am using an EC2 instance as a backend database server that receives open listings for an AirBnB type site. I've checked on my own browsers and phones and had others check on theres in other regions as well, and these listings load perfectly fine for us. There is one person in another region, however, who is not seeing any listings at all and receives the Failed to load resource: net::ERR_CONNECTION_RESET error instead. I even had them try clearing their cache in Chrome, but that did not help. Below are photos depicting the situation:
Click here to see the problem page (lol)
Photos depicting errors:
What I See/What Should Show Up:
Black Listings Come Up For Them
Here Are The Errors They Receive
Here are the Inbound settings for my security group
I'm thinking it may be a firewall issue, but i'm just not sure. Any help would be greatly appreciated, thank you!
i would suggest you check the security group in which your machine is, since it's possible that you're not allowing traffic to reach your machines.
it's possible that your location IP is open to the API but not other IP's.
I've tried to reach your page from my place and it's timing out as well, that points to the security group.
if possible share a screenshot of the security group set up on your machine, that will help diagnose further.
Related
I have made a simple full stack application that uses a postgreSQL database. When previewing the site on desktop it works fine and is able to retrieve all the information with no problem so long as my backend server is on. I am trying to preview the site on my phone using my IP address followed by the port number and it comes up just fine but only the frontend is displaying on my phone. I am unable to see any information from my backend or database. Does anyone know why that is or how I can fix that to display on my phone (without hosting the site)?
1.Maybe it's just cashing issue.
check your mobile phone browser cash setting.
In general, browsers use caching technology for performance reasons. Caching refers to storing values that you previously requested locally and then reusing old values without using new values when a similar request comes in.
2.Maybe it's a front-end css problem.
If design-related elements such as css are not accurate, problems that cannot be seen on the screen may occur even if server data is imported normally.
3.Or maybe front-end can't get data from the server at all.
In this case, it is necessary to debug the server source, check whether it is sent normally on the screen, and check whether the response is received normally through the network terminal.
After checking the three above, even if you can't solve the problem,
At least you'll know exactly what the problem is.
I am unable to access Google Cloud DNS page.
All it shows is:
"DNS API is being enabled. This may take a minute or more."
Then it reloads and repeats showing the same message.
The API is already enabled, and the records I created works. No problem with DNS.
I need to modify records, but I can't because of this problem.
I tried opening the page in different computers and different browsers without addons, same result.
If there is a better place to ask, please do tell.
Thank you.
You should be able to access the page regardless of what computer / browser you're using.
If you cannot it's either a temporary outage which you can check here or a bug.
The only thing to do here is to contact paid support for more immediate help and if the time is something you can afford report this at Google's IssueTracker and get help for free - however it may take a few days. It is possible that only you are affected. Please describe the issue in as much detail as possible - this will expidete the process.
I've just created a new MongoDB account and I'm now trying to connect the free cluster I created via MongoDB Compass Community application but I'm getting a 'Authentication Fail' error being displayed.
This is what I've checked so far:
From my MongoDB Clusters section when I clicked on the Connect (…) button which then gives you various options. From there, I selected 'Connect with MongoDB Compass' and copied the connection string.
This was detected as expected by the Compass and the information was filled automatically in all the relevant fields and I also filled the password by copy/pasting it into the relevant field. 100% sure it is correct.
I checked that the username used was indeed set up as an admin and it is.
I checked my Authentication database was correct and it is.
I've checked that my public IP was added to the whitelist and it is. The only thing I've noticed is that when I added my public IP address, it added a /32 at the end. Is that the port?
But I'm not quite sure what else to test for to resolve this problem.
Any suggestions?
Thanks.
I eventually found out what the problem was after speaking to someone from MongoDB support Team!
Everything was done correctly except for one thing. I was being impatient after changing my Cluster User's password. It can take up to 2 minutes for the system to be updated and therefore to allow Compass to access it.
Once I waited a couple of minutes, I was able to login as expected in Compass.
I still can't quite believe I wasted so much time on such a simple issue but the main thing is that it is resolved.
I did send them some feedback as a lot of things could have been done a lot better:
Highlight it better in their documentation i.e. red??
Make the "warning" message displayed on the webpage after updating the user details more obvious. It was right in my face and never spotted it appear or disappear as once I'd update the user detail on the website, I'd swap immediately to Compass to try to login. By the time, I'd be done, well over 2 minutes would elapsed and the message would be long gone, so not very useful the way it is currently done.
Instead of just saying: 'Authentication Fail', which is correct, the message could read differently when it knows the user is being updated i.e. 'Authentication Fail - Please try again in a few minutes as we're updating this user's details'... Something like this anyway.
So, remember to be patient when changing your user's details in MongoDB and if you are, then yes, you will have a database up and running in the cloud in 5 minutes or less! :)
We keep static files (images, javascript, and css) for our websites stored in a Google Storage bucket with different folders for different types of resources. Each file is accessed via its name coupled with a custom subdomain mapped via a CNAME record to the appropriate Google Storage bucket.
This approached has worked fine. Today, however, when attempting to access our main website in Chrome's incognito (private browsing) mode, all pages on the site wouldn't load. After some detective work, we've determined that the problem is with the files stored at Google Storage, which are not loading.
Unfortunately, this doesn't seem to be a problem specific to Google Chrome. It occurs in the private browsing modes in Firefox and Internet Explorer as well (at least on the Windows 8.1 Professional platform we're using for testing).
The problem appears to occur only if we use the CNAME-based approach for accessing a file. For example, if this method is used in a private browser window to access one of our image files on Google Storage,
Image of a crowd on Google Storage - direct access to Google Storage
the file can be viewed without a problem. If, on the other hand, the file is viewed in a private browsing window using the CNAME approach, like this
Image of a crowd on Google Storage - access via CNAME
the image will not load.
What's worse, for reasons we don't completely understand, once this problem occurs in a private browsing window, it will continue to interfere with the proper viewing of the website in regular (non-private browsing) browser windows in the case of some browsers.
Has anyone encountered this problem and, if so, found a solution for it?
Thanks in advance for any tips or suggestions.
UPDATE (2015-05-26)
This problem is still under investigation. It may be ISP-specific, although our ISP (Verizon) believes it is a problem on Google's end. An attempt to resolve the problem yesterday by tweaking some DNS settings seemed to solve the problem, but that was only temporary. We began to experience the problem again today. I will update this posting further as more information becomes available.
ADDITIONAL UPDATE (2016-08-25)
(Note: I originally wrote this update on 2015-05-26, but failed to post it, and discovered it today. I'm adding it to complete the description of the issue.)
This issue has been resolved. I cannot say for certain what the source of the problem was, but I can give further information on what exactly the nature of the problem was and what may have solved it.
As I mentioned in the comments below, this appears to have been an issue that was relatively isolated. Further investigation revealed that the problem was occurring only with access to the particular subdomain through Verizon Internet service (land-based or mobile) in the U.S. I do not know if the problem was a regional problem within the Verizon system, or throughout the entire Verizon system. But I do know it affected both landline and mobile access using Verizon.
The problem also evolved. What started as a problem accessing files at the subdomain in a browser's incognito mode became a problem regardless of what browsing mode was used. That said, it was only a problem if the attempt to load files from the subdomain was used with a browser. The files could be retrieved with no problem with, for example, wget. Also, pinging the subdomain also worked fine over the Verizon network.
As the problem became more acute, I decided to do a thorough check of the DNS settings related to the subdomain. Here is where I discovered what may have been causing the problem. There was a slight discrepancy between the DNS settings at the domain registrar and the (separate) DNS service that we use.
The discrepancy didn't lead to conflicting reports as to how the subdomain should be resolved (which is probably why this problem hadn't occurred in the past). But, if I recall correctly, it led to the DNS service providing the CNAME record for the subdomain, without the registrar's DNS information fully confirming that the DNS service had the right to provide that information.
This discrepancy was corrected. Within an hour or two, the problem resolved itself -- anyone viewing the file using the two links above should be successful with both links.
I cannot say for certain, however, whether the change to the DNS settings we made to resolve the discrepancy, or some updating at Verizon, was responsible for the problem being resolved. I will say, however, that I never reported the issue to Verizon. (I didn't get that far.)
Although the DNS discrepancy had existed for more than a year or two, and had not created any problems that we were aware of, I personally think it is what caused the problem.
I'm running a webapi on an Azure website that makes calls to external web services. The webapi handles approximately 2K-3K requests per minute.
Periodically, lots of socket errors start occurring that indicate: "An attempt was made to access a socket in a way forbidden by its access permissions". This error seems to occur regardless of the ip address of the external web service.
At first, I thought it might be ephemeral port exhaustion, but I've limited "connectionManagement" to a maximum of 100 connections.
What would be causing this?
Thanks very much. Happy to provide whatever information might be helpful.
Update 6/1: - doesn't work per 6/2
I added the following to my web.config system.net section:
<defaultProxy enabled="false" useDefaultCredentials="false">
<proxy/>
<bypasslist/>
<module/>
</defaultProxy>
It appears to have helped as I haven't seen this issue in the last 6 hours. I have no idea why this would actually help though as I'm not using any proxy-related stuff.
Any thoughts?
Update 6/2:
Adding the defaultProxy doesn't actually appear to help. The problem is still occurring. Back to the drawing board.
I've finally figured out the cause of this problem. The issue was occurring due to port exhaustion.
I was using an NLog email target which was grabbing and holding onto too many SMTP connections over time (despite the 100 max connection limit). After removing the email target, the issue no longer occurs. I haven't figured out why NLog was exhibiting this behavior.