Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
A 500 Internal Server Error on an HTTPS page means the server or application failed while processing the request. The certificate is not automatically the cause: TLS negotiation can succeed and the web server, reverse proxy, rewrite layer, or application can still generate the 500 response. Reproduce the exact HTTPS URL, record the time and response headers, then use the origin logs to identify the failing component before changing certificates or other production settings.
This guide gives a safe diagnostic sequence for IIS, Apache, Nginx, reverse proxies, and WordPress. It also explains how to distinguish an origin failure from an error generated by a CDN or proxy.
What an HTTPS 500 error actually means
HTTP status 500 is a server-side failure. Microsoft describes the IIS form as a problem occurring on the web server that hosts the site when the response is returned. Typical IIS causes include application syntax errors, unreadable or invalid web-server or application configuration, and a stopped site. An application can also return 500 after a database connection failure or an uncaught exception.
HTTPS adds a TLS handshake and certificate selection before the HTTP request is handled. A successful handshake proves only that the client and server negotiated encryption; it does not prove that the HTTPS virtual host, proxy, rewrite rules, permissions, or application code are healthy. A newly enabled HTTPS listener can therefore expose a bad configuration even when the certificate is valid and the HTTP URL still works.
#1 Best Overall
Use the error page as a symptom, not a diagnosis. The useful evidence is the server status and substatus, the exact URL and timestamp, response headers and body, and the exception or configuration line recorded by the origin.
First, define the failure’s scope
Do not edit several settings at once. Establish whether the problem is global, path-specific, or limited to one client route.
- Open the exact
https://URL that fails and save the timestamp in UTC or the server’s local time. - Check the equivalent
http://URL, if it is still available. Note whether HTTP succeeds, redirects, or fails with the same status. - Request a known-good static file such as an image, stylesheet, or plain text file. A static file succeeding while a dynamic page fails points toward application, rewrite, or proxy handling.
- Try another application path and, for WordPress, both the front end and
/wp-admin. - Record whether every HTTPS path fails, only one route fails, or only authenticated or POST requests fail.
- Capture response headers and the response body. A proxy name, origin server header, request ID, or branded error page can show which layer generated the response.
From a shell, a header-only request can preserve useful evidence without submitting a form:
curl -vk -I https://example.com/pathThe -v output shows TLS and connection details; the HTTP status, headers, and body still need to be compared with the server logs. Replace the example URL with the failing address and avoid pasting credentials or tokens into shared logs.
Preserve evidence before changing configuration
Write down the complete URL, query string, client time, server time zone, status code, any IIS substatus or HRESULT, and the response headers. Save a copy of the current virtual-host, server-block, rewrite, proxy, and application configuration before editing it. If the site is managed by a host, send this evidence with the request so support can search the correct log interval.
- Application detail: exception type, message, and call stack from the application or event log.
- Web-server detail: IIS
sc-statusandsc-substatus, Apache or Nginx error-log entries, and the selected HTTPS host. - Proxy detail: edge and origin status headers, request IDs, and whether the proxy could connect to the origin.
- Configuration detail: the exact file and line named by an IIS 500.19 response or by a web-server parser.
A generic browser page often hides the useful exception. Enable detailed errors only in a controlled environment or for a restricted administrator request, and disable them again after collecting the information; detailed errors can disclose paths, modules, and sensitive data.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Rank #2
Read the logs immediately after reproducing the 500
IIS: IIS logs, HTTPERR, and application logs
Start with the IIS log entry created at the reproduction time. Check sc-status and sc-substatus, the requested URI, and the site that received the request. If HTTP.sys rejected the request before IIS processed it, the entry may be in the HTTPERR logs instead. For an application exception, inspect the application log or Windows event log for the exception type, message, and call stack.
When the basic entry is insufficient, use IIS detailed errors or Failed Request Tracing (FREB) for the failing status. Restrict tracing to the affected site and status range, reproduce once, and then turn tracing off or narrow its scope. The resulting trace can show whether the request failed in authentication, URL rewriting, proxying, a module, or application execution.
Apache: error log and selected HTTPS virtual host
Read the Apache error log at the exact failure time. Confirm which virtual host answered the request and whether a rewrite, proxy, permission check, or application handler emitted the error. A certificate can be valid while the HTTPS virtual host points to a different document root, backend, or rewrite policy than the working HTTP host.
Nginx: error log and upstream details
Inspect the Nginx error log and look for upstream connection failures, permission errors, rewrite loops, and configuration parsing messages. Distinguish an Nginx-generated 500 from a response passed through from an upstream application. The upstream status and request path determine whether the fault is in Nginx or the application behind it.
WordPress: PHP and WordPress debug logs
Review the web-server error log, PHP error log, and wp-content/debug.log when WordPress logging is enabled. A stack trace that names a plugin, theme, or PHP file is more actionable than the browser’s generic page. Keep debug display disabled for public visitors and remove or protect logs after troubleshooting.
Compare the working HTTP configuration with HTTPS
Make a side-by-side comparison rather than assuming the HTTPS block inherited every HTTP setting. Check these items in order:
- Listener and host selection: the HTTPS socket, address, port, and hostname must match the request.
- Document root and application handler: HTTPS should point to the intended files, runtime, and upstream.
- Certificate and private-key paths: paths must exist, be readable by the service account, and belong to the intended host. A certificate-path problem normally causes a TLS error, but a mis-selected host can route an otherwise successful TLS connection to the wrong application.
- Redirect and rewrite rules: compare HTTP-to-HTTPS redirects, canonical-host rules, path rewrites, and conditions that may create loops or send a request to an unavailable backend.
- Proxy settings: verify upstream address, port, protocol, host header, timeouts, and health checks.
- Permissions and modules: ensure the HTTPS document root, configuration files, sockets, and runtime files are accessible to the service account and that required modules are installed.
- Recent changes: identify the first deployment, certificate renewal, proxy change, plugin update, or configuration edit after which HTTPS began failing.
Apache’s HTTPS documentation requires correctly matched Listen and <VirtualHost> directives. Nginx requires an HTTPS listening socket with ssl enabled and valid certificate and private-key paths in the server block. A mismatch in either platform can select the wrong configuration even though the handshake appears normal.
Fixes for IIS
When the status is 500.19
IIS 500.19 is a configuration-read failure, not a generic application exception. Use the HRESULT and the file-and-line information in the error page or log. Microsoft lists malformed XML, locked configuration sections, insufficient permissions, duplicate entries, and missing modules among common causes.
Recommended Free Tools
- Open the named configuration file and inspect the exact line and section.
- Validate XML syntax and remove an accidental duplicate entry.
- Check whether a parent-level section is locked; move the setting to the permitted level or unlock it only under your site’s change-control policy.
- Verify that the IIS worker-process identity can read the site and configuration files.
- Install or restore the module named by the error, or remove a stale module declaration.
- Redeploy a known-good configuration if the file has multiple unexplained changes, then reapply changes one at a time.
Do not overwrite the whole configuration with a sample file without preserving bindings, authentication, application pools, and site-specific settings. A backup and a minimal correction make rollback possible.
When IIS reports an application failure
Use the application or event log to identify the failing code path. Confirm that the HTTPS binding maps to the intended site and application pool, that the pool is running, and that the runtime version and environment variables match the working HTTP path. If only one endpoint fails, test its dependencies, such as a database or external service, rather than changing TLS settings.
When HTTPERR contains the rejection
An HTTPERR entry indicates that HTTP.sys rejected the request before normal IIS processing. Correlate the timestamp, host, and status with the binding, request size, connection state, and certificate/hostname selection. Correct the binding or lower-layer condition named by the entry before investigating application code.
Fixes for Apache
Verify the HTTPS listener and virtual host
Confirm that Apache listens on the address and port used by the request and that the HTTPS <VirtualHost> matches the requested hostname. Ensure the SSL module is loaded and that the certificate and key files are the intended pair. A configuration test should pass before a reload; if it fails, restore the last known-good file and correct the reported directive.
Rank #4
Check rewrites, proxying, and permissions
Compare rewrite rules in the HTTP and HTTPS hosts. A rule that assumes a particular scheme, host, or path can redirect repeatedly or send HTTPS traffic to a nonexistent location. For proxied applications, verify the upstream URL and headers. Check that Apache can read the document root and that the application user can write only to directories that genuinely require it.
After a reload, reproduce one request and read the error log immediately. Do not treat a successful configuration reload as proof that the application is healthy; it confirms syntax, not runtime dependencies.
Fixes for Nginx
Check the SSL server block
Confirm that the server block listening on the HTTPS port includes ssl and valid certificate and private-key paths. Ensure the requested hostname selects this block rather than a default server with a different root or upstream. Test the configuration before reloading and keep the previous file available for rollback.
Trace rewrites and upstream failures
Review rewrite, return, and location precedence for the failing path. Then inspect proxy_pass or other upstream directives, including protocol, port, host header, and timeout. An Nginx error-log line that says the upstream returned a status identifies an application response; a connection-refused, timeout, or permission message points to the path between Nginx and the upstream.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsRetest a static asset and the dynamic endpoint separately. This prevents an application exception from being mistaken for an SSL listener problem.
WordPress: isolate .htaccess, plugins, themes, and PHP
WordPress lists a corrupted .htaccess file, plugin conflicts, and theme conflicts as common Internal Server Error causes. Work in a reversible order and make one change at a time.
- Back up the site files and database, and record the current permalink and plugin state.
- Temporarily rename
.htaccess(for example, to.htaccess.disabled) so Apache cannot load its rules. Test the HTTPS front end and/wp-admin. If the error disappears, regenerate permalinks and inspect the old rules for a bad rewrite. - If the error remains, disable plugins without relying on the dashboard by renaming the plugins directory or deactivating plugins through the site’s administrative database tools. Restore the directory name and reactivate plugins individually until the failing component is identified.
- Switch to a default WordPress theme. A theme-specific PHP error can affect the front end while administration still works, or it can break both routes.
- Read the PHP and WordPress logs for the named file, function, or memory/runtime failure. Correct the component or roll it back to the last known-good version.
- Restore the original
.htaccess, theme, and plugin state only after each component has been tested. Leave the confirmed offender disabled or updated, then retest.
Do not leave WordPress debug output visible to visitors. Logging should help you capture the exception while protecting credentials, cookies, and database details.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.When a CDN or reverse proxy is in front of the site
First determine whether the 500 was generated at the edge or by the origin. Inspect the response body and headers for the proxy name, edge request ID, cache indicators, and origin-status headers. Then compare a request through the public hostname with a controlled request to the origin, if your hosting arrangement permits it.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Cloudflare notes that an “Error establishing database connection” page is a common HTTP 500 that typically indicates an origin web-server issue. If the proxy can reach the origin but the origin returns 500, fix the origin application or configuration. If the edge cannot connect, investigate origin reachability, firewall rules, health checks, and proxy-to-origin TLS settings. Involve the site administrator or hosting provider when you do not have origin-log access.
Do not rotate certificates solely because a generic 500 page appears. Certificate problems usually present as a browser TLS warning, handshake failure, hostname mismatch, or proxy-specific TLS error; an HTTP 500 means some server-side HTTP component produced a response after (or during) request handling.
Platform comparison at a glance
| Platform or layer | Most useful first logs | HTTPS wiring to verify | Frequent 500 path |
|---|---|---|---|
| IIS | IIS logs with sc-status/sc-substatus, HTTPERR, application and event logs, then detailed errors or FREB |
Site binding, selected site, application pool, certificate binding, modules and configuration inheritance | 500.19 configuration errors, stopped site, syntax or application exceptions |
| Apache | Apache error log and application log | Listen, matching <VirtualHost>, SSL module, certificate/key paths |
Rewrite, proxy, permission, handler, or virtual-host mismatch |
| Nginx | Nginx error log and upstream application log | HTTPS listen with ssl, certificate/key paths, server-block selection |
Rewrite, permission, upstream connection, timeout, or application response |
| WordPress | Web-server and PHP logs plus wp-content/debug.log |
Web-server HTTPS block, rewrite rules, PHP handler and proxy path | Corrupt .htaccess, plugin or theme conflict, PHP exception |
| CDN or reverse proxy | Edge response headers and origin logs correlated by request ID and time | Proxy-to-origin hostname, port, protocol, trust and health checks | Origin 500, unreachable origin, failed health check, or edge-generated response |
Retest after the correction
Use the same HTTPS URL and test the same request method that originally failed. Then verify:
- the original dynamic page and its redirects;
- a known-good static asset;
- the application’s key workflow, such as login, form submission, or checkout;
- for WordPress, both the front end and
/wp-admin; - the public hostname through the proxy and the origin path when authorized;
- fresh IIS, Apache, Nginx, PHP, or application logs for new 5xx responses.
Keep the captured before-and-after timestamps and configuration diff. If the 500 returns, that record shows whether the same component failed or a later change introduced a new fault.
When to escalate
Contact the host or server administrator when you cannot read origin logs, the account lacks permission to change the HTTPS binding, the application depends on a managed database, or the proxy hides the origin response. Send the exact URL, timestamp and time zone, status and substatus or HRESULT, response headers, scope of affected paths, and the relevant log excerpt with secrets removed. A request that includes this evidence is much more actionable than “HTTPS is broken.”
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
