You moved your site to a new host, updated DNS, and then users started reporting 502 Bad Gateway or 504 Gateway Timeout. These errors rarely mean the site is permanently broken — most often they point to a mismatch between the new server environment and what the application expects. This guide explains how to diagnose 502 and 504 after a migration, what to check first, how to read server logs, and how to verify the fix without breaking anything else.
What 502 and 504 actually mean
502 Bad Gateway means the server acting as a gateway or proxy received an invalid response from the upstream server. In a typical nginx plus PHP-FPM setup, nginx is the gateway and PHP-FPM is the upstream. When nginx cannot reach PHP-FPM, when the application crashes, or when the upstream server is misconfigured, nginx returns 502.
504 Gateway Timeout means the gateway did not receive a timely response from the upstream server. This usually points to a timeout setting that is too low, a slow database query, a script that runs longer than allowed, or an external API call that hangs.
After a migration, both errors often appear because the new environment has different PHP versions, different timeout limits, different permissions, a different web server configuration, or a different database server. The application code may be fine, but the environment is not. That is why the same site that worked for years on the old host can start throwing 502 and 504 immediately after the move.
First checks after migration
Start with the basics before diving into configuration files:
— confirm DNS has fully propagated and the domain points to the new server IP;
— check whether the site loads directly via the new server IP;
— verify SSL certificates are valid on the new server and not expired;
— check web server error logs for upstream errors;
— confirm PHP-FPM or the application server is running;
— check file and directory permissions and ownership.
If the site works via IP but not via domain, the issue is likely DNS or SSL. If it does not work via IP either, the issue is on the server itself. This single test narrows the problem down significantly and saves time.
It is also worth checking whether the new host has a firewall or proxy in front of the server. Some managed hosts put their own reverse proxy between the user and the application, and that proxy can return 502 or 504 independently of your configuration.
Common causes of 502 after migration
Typical causes of 502 after a move:
— PHP-FPM socket path changed and nginx still points to the old one;
— PHP version mismatch between old and new host;
— missing PHP extensions required by the application;
— incorrect file permissions or ownership;
— application memory limit too low;
— database connection errors;
— SELinux or AppArmor blocking the connection between nginx and PHP-FPM.
A frequent scenario: the new host uses a different PHP-FPM socket path, for example /run/php/php8.2-fpm.sock instead of /var/run/php-fpm.sock. The nginx configuration still references the old path. The web server starts, but every request to PHP fails with 502. In the nginx error log you will see a line like "connect() failed (111: Connection refused) while connecting to upstream". That single line tells you the socket is wrong or PHP-FPM is not running.
Another common case is a PHP version mismatch. The application may use functions or syntax that were removed or changed in the new PHP version. In that case PHP-FPM starts but crashes on the first request, and nginx returns 502. The PHP-FPM log will show a fatal error with the exact function or file that caused the crash.
Common causes of 504 after migration
Typical causes of 504 after a move:
— proxy_read_timeout or fastcgi_read_timeout set too low;
— slow database queries after migration;
— external API calls that time out;
— heavy scripts that ran faster on the old server;
— DNS resolution delays inside the application;
— database server on a different network with higher latency.
504 is often a tuning issue rather than a broken configuration. The new server may have stricter timeout defaults, or the database may be slower because it has not been optimized yet. If the application makes external API calls, those calls may now take longer because the new server is in a different region.
A useful test is to temporarily increase the timeout values and see whether the 504 disappears. If it does, the issue is performance-related and needs deeper investigation. If it does not, the issue may be a hanging connection or a deadlock in the application.
How to diagnose the root cause
A practical sequence for diagnosis:
— check nginx error log for "upstream timed out" or "connect() failed";
— check PHP-FPM log for fatal errors;
— check application log for exceptions;
— test database connection from the server command line;
— test the site with a simple static file to isolate PHP issues;
— compare PHP settings between old and new host;
— check whether the new host has a proxy or firewall in front of the server.
For response time checks, you can use TTFB checker to see how long the server takes to respond. If TTFB is high, the issue is likely upstream or database-related. If TTFB is normal but the page still fails, the issue may be in a specific script or API call that runs after the first byte.
For a broader check after migration, SEO audit can help verify DNS, SSL, redirects and server response in one place. This is useful when you want to make sure the migration did not break anything else — for example, redirects, canonical tags, or SSL chains.
How to fix 502 and 504
Fix steps depend on the cause:
— update nginx configuration to match the new PHP-FPM socket;
— install missing PHP extensions;
— increase memory_limit and max_execution_time if needed;
— increase proxy_read_timeout and fastcgi_read_timeout;
— optimize slow database queries;
— fix file permissions and ownership;
— check SELinux or AppArmor policies if the host uses them;
— restart PHP-FPM and nginx after changes.
After each change, test the site again. Do not change multiple settings at once — you will not know which one fixed the issue. A disciplined one-change-at-a-time approach is slower at first but much faster overall, because it prevents guesswork.
If the issue is a slow database, consider adding indexes, enabling query cache, or moving the database to a faster disk. If the issue is an external API, consider adding a timeout and a fallback so that a slow third-party service does not take down your whole site.
How to verify the fix
Verification checklist:
— site loads via domain and via IP;
— no 502 or 504 in server logs;
— SSL certificate is valid;
— redirects work correctly;
— TTFB is within normal range;
— search consoles show no new errors;
— key pages return HTTP 200 and render correctly.
If the site is stable for 24 to 48 hours after the fix, the migration issue is likely resolved. It is worth checking the logs again after a few days, because some errors appear only under load or at certain times of day.
How 502 and 504 affect SEO
Search engine bots treat 502 and 504 as temporary server errors. If a bot sees these errors repeatedly, it may slow down crawling and eventually drop pages from the index. The impact depends on how long the errors last and how often the bot encounters them.
What to do from an SEO perspective:
— fix the errors as soon as possible;
— check Google Search Console and Yandex Webmaster for crawl errors;
— request re-crawl of affected pages after the fix;
— monitor organic traffic for a few weeks after the migration.
If the errors lasted only a few hours, the SEO impact is usually minimal. If they lasted days, some pages may have dropped from the index, and it can take weeks to recover. This is why keeping the old server alive during the DNS transition matters — it prevents bots from hitting a dead end.
FAQ
Why did 502 appear only after migration?
Because the new server environment differs: PHP version, socket path, permissions, or extensions. The application code may be fine, but the configuration is not. The most common cause is a mismatched PHP-FPM socket path in nginx.
Is 504 always a server timeout issue?
Not always. It can also be caused by slow database queries, external API calls, or DNS delays inside the application. Increasing timeouts may hide the symptom without fixing the cause.
How do I check if DNS has propagated?
Use online DNS lookup tools and test from different devices. If different resolvers return the new IP, propagation is in progress. Full propagation is complete when all checked points return the new IP.
Can SSL issues cause 502?
SSL issues usually cause different errors, but a misconfigured SSL on the new server can break the connection between proxy and upstream, leading to 502. Check the SSL chain and certificate validity first.
What should I check first?
Check server error logs first. They usually point directly to the cause: upstream timeout, connection refused, or PHP fatal error. The nginx error log is the fastest way to narrow down the problem.
How long should I wait after fixing?
Test immediately after each change. If the site is stable for 24 to 48 hours, the issue is likely resolved. Check logs again after a few days to catch load-related errors.
Can 502 and 504 affect SEO?
Yes. If search engine bots receive these errors, pages may be dropped from the index. Fix the issue as soon as possible and request re-crawl of affected URLs.
Do I need to update DNS again after fixing?
No, unless you change the server IP. DNS changes are only needed when the server address changes. If you only fixed the application configuration, DNS stays as is.
Should I keep the old server running after migration?
Yes, for at least the duration of the old TTL, and preferably for 48 hours. This prevents users and bots with cached DNS from hitting a dead end and seeing errors.
What if the new host uses a proxy in front of my server?
Some managed hosts add their own reverse proxy. In that case, 502 and 504 may come from the host proxy, not your nginx. Check the host documentation and ask support whether a proxy is in front of your server.
