Skip to content

NPM issue after Migration from Digital Ocean

0

We recently migrated our DigitalOcean droplet to an AWS EC2 instance by creating a full copy of the system. The configurations remain the same as they were on DigitalOcean. Our networking is properly set up, and we can access the AWS instance via SSH.

On our server, we use NGINX Proxy Manager (NPM) to manage different hosts and route traffic. Previously, on DigitalOcean, we had our DO public IP set as the Forward Hostname in NGINX for various services. However, after changing this to our AWS Elastic/Public IP, the website does not load and stays stuck on "Loading."

What We Have Checked So Far:

Networking is functional

  • The EC2 instance has proper networking, and we can SSH into it.

  • The instance has a static private IP and an Elastic IP assigned.

  • The frontend server can ping our backend cloud server, and vice versa.

NGINX Proxy Configuration

  • We updated the Forward Hostname/IP from the DigitalOcean public IP to the AWS Elastic IP in NGINX Proxy Manager.

  • No firewall rules seem to be blocking connections.

Backend Services

  • Backend was originally hosted on the DigitalOcean droplet using Docker containers for a few of the hosts.

  • We suspect that some API calls or services may still be referencing the old DigitalOcean IP instead of the new AWS instance.

However, after searching the backend configuration, we haven't found direct references to the old DO IP.

Potential Causes We Are Investigating:

Do we need to update any Docker network settings on the AWS instance?

Should we look for hardcoded DigitalOcean IPs on our Nightingale server (our main service hosting platform)?

Are there any AWS security groups or inbound rules that could be blocking traffic?

Do we need to update any DNS settings or environment variables pointing to the old backend?

Is NPM building correctly?

At this point, we are unsure what additional steps we should take to ensure the website loads correctly after updating the forward hostname in NGINX.

Any advice or insights would be greatly appreciated!

2 Answers
0

Based on the information provided, there are several potential causes for the website not loading after migrating from DigitalOcean to AWS EC2. Here are some steps and areas to investigate:

  1. Security Group Configuration: Ensure that the EC2 instance's security group allows inbound traffic on the necessary ports (e.g., 80 for HTTP, 443 for HTTPS). Double-check that the rules allow traffic from anywhere (0.0.0.0/0) or the specific IP ranges you want to allow.

  2. Network ACLs: If you're using custom Network ACLs in your VPC, verify that they allow both inbound and outbound traffic on the required ports, including ephemeral ports (1024-65535) for return traffic.

  3. Route Table: Confirm that your subnet's route table includes a route for internet-bound traffic (0.0.0.0/0) pointing to the internet gateway.

  4. NGINX Configuration: Review your NGINX configuration files to ensure they are properly set up for the new environment. Check for any hardcoded references to the old DigitalOcean IP or domain names.

  5. Docker Network Settings: Inspect your Docker network configurations. Ensure that the containers are properly networked and can communicate with each other and the host system.

  6. DNS Settings: Verify that all DNS records have been updated to point to the new AWS Elastic IP. DNS propagation can take some time, so ensure enough time has passed for changes to take effect.

  7. Environment Variables: Check all environment variables in your application and Docker containers for any references to the old DigitalOcean IP or hostname. Update these to reflect the new AWS environment.

  8. Application Code: Review your application code for any hardcoded references to the old IP or domain. This includes configuration files, API endpoints, and database connection strings.

  9. SSL Certificates: If you're using SSL, ensure that the certificates are properly installed and configured for the new domain or IP.

  10. Logs and Monitoring: Enable detailed logging for NGINX, your application, and Docker containers. Monitor these logs for any error messages or warnings that might indicate the source of the problem.

  11. Firewall Settings: Check the instance-level firewall (if applicable) to ensure it's not blocking incoming connections.

  12. Instance Reboot: As a troubleshooting step, try rebooting the EC2 instance. This can sometimes resolve connectivity issues, especially after significant changes.

  13. Load Balancer: If you're using a load balancer, verify its configuration and health checks are properly set up for the new EC2 instance.

If none of these steps resolve the issue, you may need to use network diagnostic tools like tcpdump or Wireshark to capture and analyze the network traffic. This can help identify where exactly the requests are getting stuck.

Remember to test each change incrementally and keep detailed notes of your troubleshooting steps. If the problem persists, you might consider setting up a new EC2 instance from scratch and migrating your application components one by one to isolate the issue.

Sources
webpage not accessible via Elastic IP on EC2 | AWS re:Post
The SSH was right and suddenly breaks | AWS re:Post
No longer have http access to EC2 instance after elastic IP associated | AWS re:Post
Instance running but can't connect | AWS re:Post

answered 2 years ago

AWS
EXPERT

reviewed 2 years ago

0

If I follow your description correctly, your backend targets are Docker containers on the same instance as NPM? If so, I would set the forwarding IP to 127.0.0.1 and the port the container is listening on rather than using the Public IP. In AWS EIPs (Public IPs) are not defined on the instance. The instance has a private IP from the VPC and in the higher up portion of VPC the Public IP is NAT'd to point to the private IP. By pointing your forward IP to the Public IP you are sending traffic back out of the instance to the Public IP and then back into the instance. Essentially looping back to NPM. Using the localhost (127.0.0.1) will keep the traffic on the host and just forward to the port on the local container.

(If your backend containers are on other EC2 hosts, use the Private IPs of those instances.)

AWS
EXPERT

answered 2 years ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.