Networking & DNSAdvanced

How to Fix ERR_CONNECTION_TIMED_OUT on a Subdomain When the Main Domain Works

Quick Answer ERR_CONNECTION_TIMED_OUT means the browser did not receive a usable response within the permitted time. If the main domain opens but a subdomain...

Bison Technical Team Enterprise IT specialists

Updated 14 Sep 2026 16 min read 0 total views

Quick Answer

ERR_CONNECTION_TIMED_OUT means the browser did not receive a usable response within the permitted time. If the main domain opens but a subdomain times out, the internet connection is not automatically at fault. The subdomain may use a different DNS record, document root, PHP application, database workload, firewall rule or cache configuration.

When the website begins working again without any code change, the incident was probably temporary—but that does not prove its exact cause. Common explanations include a blocked visitor IP that was later unblocked, short-lived hosting congestion, exhausted PHP workers, a delayed MySQL query, a database lock or an overloaded security layer. Use timestamps, tests from a second network, hosting resource graphs, access logs and application timing to identify the real cause before restoring backups or changing code.

Complete Article

What Does ERR_CONNECTION_TIMED_OUT Mean?

ERR_CONNECTION_TIMED_OUT is a browser-level connection failure. It indicates that the browser waited for the requested website but did not receive a usable response in time. The delay can occur before a connection is established or while the server is processing the request.

The message does not, by itself, identify which component failed. Potential causes include:

A local internet, proxy, VPN, DNS or firewall problem.
An unreachable or incorrect DNS destination.
An IP address blocked by a hosting firewall, web application firewall (WAF) or security rule.
Temporary overload on a shared-hosting server.
Exhausted PHP workers, processes, memory, CPU or disk I/O.
A PHP script waiting on a slow database query, external request or locked resource.
A CDN, reverse proxy or upstream server that stopped responding.

Hostinger’s current troubleshooting guidance similarly treats ERR_CONNECTION_TIMED_OUT as a symptom that can originate on either the visitor side or the website/server side. It recommends testing the internet connection, proxy and VPN as well as investigating server configuration and resource availability. See Hostinger’s official guide: How to fix the ERR_CONNECTION_TIMED_OUT error.

Why Can the Main Domain Work While the Subdomain Times Out?

A working main domain does not prove that every subdomain is healthy. For example, example.com and kb.example.com may be hosted under the same account while still using different components.

Component	Main domain	Subdomain
DNS record	May point to one IP or CDN	May point directly to another server
Document root	`/public_html/`	`/public_html/kb/` or another directory
Application	WordPress or static PHP	Custom PHP knowledgebase
Database activity	Light or cached queries	Search, article, view-count and related-content queries
Security rules	General rules	Separate `.htaccess`, WAF or rate-limit rules
Caching	CDN/page cache enabled	Dynamic pages may bypass cache

The main website may therefore remain fast while the subdomain waits for PHP or MySQL. Conversely, only one visitor may see a timeout if the hosting firewall blocks that visitor’s public IP.

An Anonymized Real-World Incident

Consider the following sequence involving a custom PHP knowledgebase:

The main domain opened normally.
The knowledgebase subdomain displayed ERR_CONNECTION_TIMED_OUT.
The hosting provider confirmed that the subdomain existed and its DNS record was present.
An access restriction affecting the visitor IP was removed.
An internal test reached the server and eventually received HTTP 200, but some dynamic PHP requests reportedly took tens of seconds.
A short time later, the website began opening normally and quickly without any code or database change.

This sequence supports a temporary access-control, hosting-resource or application-delay explanation, but it does not prove which one was responsible. The IP unblock may have restored access, a server load spike may have ended, PHP workers may have become available, or a temporary database wait may have cleared.

The correct conclusion is therefore:

The outage was probably temporary and may have been server-side or access-control related. Slow PHP or MySQL activity is plausible, but it should not be described as the confirmed root cause unless logs or query timings prove it.

HTTP 200 Does Not Always Mean the Website Is Healthy

An HTTP 200 OK response only tells you that the request eventually completed successfully. It does not mean that the page responded quickly.

For example, a dynamic article page that returns 200 after 40 seconds is technically successful but operationally unhealthy. A visitor, proxy, CDN or monitoring service may stop waiting before that response arrives. This can create the confusing situation in which a hosting technician reports “HTTP 200” while a visitor receives a timeout.

Always record both:

The final HTTP status code.
Connection time, time to first byte (TTFB) and total response time.

First Diagnosis: Determine Who Is Affected

Before editing PHP or restoring a backup, test the same URL under controlled conditions.

Test from another network

Open the affected subdomain using:

The normal office or home broadband connection.
A mobile phone using cellular data with Wi-Fi disabled.
Another trusted external network, if available.

Interpret the result as follows:

Test result	Most likely area to investigate
Works on mobile data but not broadband	Public IP block, ISP route, local DNS, proxy or firewall
Fails on every network	Hosting server, DNS destination, CDN/WAF or application backend
Homepage works but dynamic articles time out	PHP code, database queries, locks or PHP workers
Static images load but PHP pages do not	PHP processes, application bootstrap or database connection
Only one article fails	Article-specific data, query, plugin, template or malformed content
Recovers without any change	Temporary load, rate limit, firewall block, lock or provider incident

This comparison is often more useful than repeatedly clearing the browser cache.

Check DNS Without Assuming DNS Is the Cause

If the browser reports DNS_PROBE_FINISHED_NXDOMAIN, the hostname did not resolve correctly. ERR_CONNECTION_TIMED_OUT is different: the name may have resolved, but the destination did not answer in time.

On Windows, open Command Prompt and run:

nslookup kb.example.com

Confirm that the returned IP address matches the intended hosting destination. Compare it with the main domain if both are supposed to use the same server:

nslookup example.com
nslookup kb.example.com

Also check for an unexpected AAAA record. A broken IPv6 destination can affect some networks even when IPv4 works. Do not delete DNS records merely because the site timed out; first compare them with the records shown by the hosting provider.

If DNS has recently changed, flushing the Windows resolver cache can remove an outdated local answer:

ipconfig /flushdns

This can help with stale local DNS information, but it will not repair overloaded PHP workers or slow database queries.

Check Whether the Visitor IP Was Blocked

An IP block becomes a strong possibility when:

The website works through mobile data but not through one broadband connection.
Other visitors can open the site.
The hosting provider reports that the server itself is reachable.
Access begins working immediately after the provider unblocks the public IP.

Possible blocking layers include:

Hosting firewall rules.
WAF or ModSecurity rules.
Login or bot-protection systems.
Rate limits triggered by repeated requests.
CDN security rules.
A deny rule in .htaccess.

Ask the provider to confirm the exact blocked IP, timestamp, security layer and rule that triggered the action. Simply unblocking an IP restores access but does not explain why it was blocked. A compromised device, aggressive crawler, broken monitoring script or repeated administrative request could trigger the same rule again.

Never publish the affected public IP, hosting account name, firewall event ID or administrator identity in a public article or forum post.

Examine Hosting Resource Usage

On shared hosting, a temporary resource spike can delay one application while another remains responsive. Review CPU, memory, disk I/O, processes and PHP-worker usage around the exact incident time.

Hostinger states that its Resource Usage section shows hosting-plan resource consumption and that the figures on ordinary web or cloud hosting are aggregated across the websites in the plan. A spike may therefore be caused by the main site, subdomain, scheduled task or another application in the same account. See How to check resource usage in Hostinger.

PHP workers deserve particular attention. A worker generally handles one PHP request at a time. When all available workers are busy, new dynamic requests wait in a queue and visitors may experience delays or timeouts. Hostinger documents this behavior in What to do if your hosting plan limits are reached.

Look for spikes in:

CPU usage.
RAM usage.
Disk I/O or IOPS.
Entry processes or process count.
PHP workers.
Database connections.
Requests and bandwidth.

Do not upgrade the hosting plan based on a single unexplained incident. First establish whether the limit was reached repeatedly and identify the request or process responsible.

Review Access, 5xx and PHP Error Logs

Record the exact date and time of the failure, including the correct timezone. Then review the logs for that period.

Hostinger’s hPanel analytics can show 5xx events with the time and requested URL, which helps identify whether one route repeatedly failed. See How to use the Analytics section on hPanel.

PHP error logging should also be enabled in production, while direct error display should normally remain disabled for public visitors. Hostinger explains that enabled PHP logs can be found in the .logs directory with filenames associated with the relevant domain or subdomain. See Where to find your website’s error logs.

An empty PHP error log does not prove that the server was healthy. Hostinger notes that PHP logs do not contain every server-, resource-, database- or DNS-related event. Hosting support may need to examine platform-level logs that customers cannot access.

Measure PHP and Database Operations Separately

If the homepage is fast but an article route such as view_article.php is slow, add safe server-side timing around major operations. Measure:

Database connection time.
Main article query time.
View-counter update time.
Category and author query time.
Related-article query time.
Comment query time.
Total PHP generation time.

A minimal PHP timing pattern is:

<?php
$startedAt = microtime(true);

// Execute one named operation here.
$stmt->execute();

$elapsedMs = (microtime(true) - $startedAt) * 1000;
error_log('kb_timing operation=related_articles duration_ms=' . round($elapsedMs, 2));

Use fixed operation labels. Do not write database passwords, session identifiers, private search terms, complete SQL parameters or personal visitor information to the log.

Check Slow MySQL Queries Correctly

Do not assume that every slow page needs a new index. First identify the query consuming the time, then inspect its execution plan.

MySQL’s EXPLAIN statement shows how MySQL intends to execute supported statements and helps reveal full-table scans, inefficient joins and unsuitable index use. Consult the official MySQL EXPLAIN documentation.

Common optimization opportunities in a PHP knowledgebase include:

Indexing columns frequently used in WHERE, JOIN and ORDER BY clauses.
Using a composite index that matches the actual filter and sort order.
Avoiding SELECT * when only a few columns are required.
Avoiding one additional query per displayed article or category—the N+1 query pattern.
Paginating large result sets.
Avoiding expensive wildcard searches such as LIKE '%term%' on every request.
Moving suitable search workloads to a properly designed full-text index.
Avoiding unnecessary COUNT(*) queries that scan large tables.
Reviewing synchronous view-counter writes performed on every article request.
Caching public category lists, popular articles and related-content results for a short period.

An index should be added only after reviewing the real query and table structure. Too many indexes consume storage and make inserts and updates more expensive.

Do Not Treat a Higher PHP Timeout as the Main Fix

PHP’s max_execution_time limits how long a script is allowed to execute. The documented default is commonly 30 seconds, although hosting configurations can differ. See the official PHP runtime configuration documentation.

Increasing that value may allow a slow request to continue for longer, but it can also keep PHP workers occupied longer and make congestion worse. It does not optimize a slow query, remove a database lock or correct an IP block.

Use a higher limit only when the workload legitimately needs more time—such as a controlled import or maintenance operation—and preferably move long-running work away from public page requests.

Can Clearing the Server Cache Fix the Problem?

Clearing a corrupted or stale cache can help in some cases, but it is not a universal timeout fix. It may temporarily make performance worse because the cache must be rebuilt.

Caching is most useful when:

Public article pages change infrequently.
Category and popular-content queries run repeatedly.
The cache is invalidated when an article is updated.
Logged-in administration pages and personalized responses are excluded.

If a site becomes fast immediately after an IP unblock, the cache clear may only be coincidental. Use logs and timing rather than assuming that the last action performed caused the recovery.

Why Restoring a Backup Is Usually the Wrong First Step

A timeout does not automatically mean that files or the database are corrupted. Restoring an older backup can overwrite:

Newly published articles.
Recent comments or feedback.
Security updates.
Configuration improvements.
Analytics or view data.

Restore only when there is evidence of a damaging code, configuration or database change and the selected backup is known to contain a healthy version. Before restoring, take a current backup and separately preserve new database content whenever possible.

If the site recovered automatically without rollback, that is evidence against treating backup restoration as the first response.

A Practical Troubleshooting Workflow

Follow this order during the next incident:

1. Preserve the evidence

Record:

Exact URL.
Exact error text.
Date, time and timezone.
Screenshot with the address bar visible.
Network used.
Whether the main domain works.
Whether a static file and a dynamic PHP page work.

2. Compare two networks

Test broadband and cellular data. This is the fastest way to identify a connection-specific or IP-specific problem.

3. Check DNS destinations

Confirm A, AAAA and, where applicable, CNAME records. Verify that they point to the intended service.

4. Check security blocking

Review WAF, ModSecurity, CDN, .htaccess, rate-limit and hosting firewall events.

5. Check hosting resources

Match CPU, RAM, I/O, processes and PHP-worker graphs to the incident time.

6. Review logs

Check access analytics, 5xx events and PHP logs. Ask hosting support for infrastructure logs if customer-visible logs are empty.

7. Time the application

Measure the database connection and each important query separately. Compare homepage, search and article routes.

8. Optimize only the proven bottleneck

Add or adjust indexes, rewrite an inefficient query, reduce synchronous work, fix the triggering security rule or address the resource limit supported by the evidence.

9. Monitor after recovery

Use an external availability check at a sensible interval. Monitor at least the homepage and one representative dynamic article URL. A homepage-only monitor can miss application-route failures.

What to Ask the Hosting Provider

Send a precise request instead of asking only why the website is down:

Please investigate the timeout affecting kb.example.com at [date and time with timezone]. The main domain was accessible, while the subdomain timed out. Please confirm whether the visitor IP was blocked by any firewall, WAF, ModSecurity or rate-limit rule and provide the triggering timestamp and rule category. Also check PHP-worker saturation, CPU, RAM, disk I/O, process limits, database connection waits and upstream errors. If a slow PHP or database operation was detected, please provide the affected request path, response time and supporting log evidence.

This request asks for evidence without exposing real domain, account or IP details in a public article.

Prevention and Best Practices

Keep external uptime monitoring for both static and dynamic URLs.
Retain access and PHP error logs long enough to investigate intermittent incidents.
Use UTC or record the timezone consistently across application and hosting logs.
Add privacy-safe performance timing to important PHP routes.
Review resource-usage trends rather than a single snapshot.
Cache suitable public content while excluding administrative and personalized pages.
Use prepared statements and validate all input.
Review query plans before adding indexes.
Rate-limit abusive traffic without blocking legitimate administrators unnecessarily.
Keep .htaccess, WAF and CDN changes documented.
Do not expose database errors, filesystem paths or credentials to visitors.
Test restoration procedures, but do not restore backups without evidence.

Frequently Asked Questions

1. Why does a subdomain time out when the main domain works?

The subdomain may use a different DNS destination, directory, PHP application, database workload, security rule or caching path. Sharing a hosting account does not make both sites operationally identical.

2. Does ERR_CONNECTION_TIMED_OUT prove that the server is down?

No. The timeout may be caused by the visitor’s network, DNS, proxy or firewall, an IP block, hosting congestion or a slow application request. Additional tests are required.

3. Can a slow MySQL query cause ERR_CONNECTION_TIMED_OUT?

Yes, indirectly. If PHP waits too long for a database operation, the browser or an upstream proxy may stop waiting. However, query timing or logs should confirm this before it is treated as the root cause.

4. Why did the website start working without any change?

A temporary server-load spike, database lock, PHP-worker queue, firewall block, rate limit, ISP route or provider incident may have cleared. Automatic recovery does not reveal which component failed.

5. If the server returned HTTP 200, why did the browser time out?

The server may have completed its request after the browser or proxy stopped waiting. HTTP 200 describes the final response status, not how quickly it was produced.

6. How can I tell whether my public IP was blocked?

Test the same URL through mobile data with Wi-Fi disabled. If cellular access works while one broadband connection consistently fails, check hosting firewall, WAF, CDN, rate-limit and local network rules.

7. Will Ctrl+F5 fix a server-side timeout?

Usually not. A hard refresh bypasses some browser cache behavior, but it does not release PHP workers, optimize SQL, remove a server firewall block or add hosting resources.

8. Should I flush DNS?

Flush DNS if records recently changed or one device may have a stale answer. It is not a fix for slow PHP, MySQL or hosting-resource exhaustion.

9. Should I increase max_execution_time?

Not as the first response. A higher timeout can hide the symptom and keep scarce PHP workers occupied for longer. Identify the slow operation first.

10. Why does the homepage open while article pages remain slow?

Article pages may execute additional queries for content, authors, categories, comments, related articles and view counters. Measure each operation and inspect slow query plans.

11. What are PHP workers?

PHP workers are processes that execute dynamic PHP requests. When all workers are occupied, additional requests wait, which can produce slow loading or timeouts.

12. Why is the PHP error log empty during a timeout?

The problem may occur outside PHP—for example in DNS, a firewall, resource throttling or the database layer. Some infrastructure events are visible only to the hosting provider.

13. Is a 503 error the same as ERR_CONNECTION_TIMED_OUT?

No. A 503 Service Unavailable response means the server returned an HTTP response indicating temporary unavailability. ERR_CONNECTION_TIMED_OUT means the browser did not receive a usable response in time.

14. Is a 504 error the same as a browser timeout?

No. A 504 Gateway Timeout is an HTTP response from a gateway or proxy that did not receive a timely upstream response. A browser-level timeout may occur without any HTTP status being returned.

15. Should I restore a backup after one timeout incident?

No, unless evidence links the failure to a damaging recent change or corruption. First collect logs, compare networks and check hosting resources. Preserve current content before any rollback.

16. What evidence should I send to hosting support?

Provide the exact URL, timestamp with timezone, screenshot, public IP privately, results from a second network, affected routes and any matching resource or error-log entries.

17. How should I monitor a custom PHP knowledgebase?

Monitor the homepage and at least one representative dynamic article or search URL. Record status code and response time, because a slow 200 response can still indicate a serious performance problem.

Final Recommendation

When a subdomain displays ERR_CONNECTION_TIMED_OUT while the main domain continues working, do not immediately blame DNS, restore an old backup or increase PHP timeouts. First establish whether the failure affects one network or everyone, and whether it affects static content, dynamic PHP pages or only one route.

If the website recovers automatically, treat the incident as unresolved—not necessarily serious, but not fully diagnosed. Preserve the timestamp, review firewall events and hosting resource graphs, and add privacy-safe timing to database-intensive PHP routes. Make configuration or code changes only after the evidence identifies the blocked layer or performance bottleneck.

Was this guide useful?

Your answer helps us keep BISONKB accurate and practical.