Fix an ownCloud Redirect Loop: HTTP, HTTPS, Host and Webroot

Updated 5 November 2026 · Standard formula, shown below

An ownCloud redirect loop usually means the server, reverse proxy, or ownCloud configuration disagrees about the public URL. These steps help align HTTP versus HTTPS, the hostname, port, and installation path so sign-in and other pages load normally. Before changing files, make a backup and identify whether ownCloud is behind a proxy or load balancer.

What You’ll Need

Administrator access to ownCloud, its server, and any reverse proxy or web server in front of it.
The public URL users should visit, including scheme, hostname, optional port, and any path such as /cloud.
A backup of the ownCloud configuration file and relevant proxy or web-server settings.
A way to inspect response headers and logs, such as browser developer tools, curl, and server logs.

Step-by-Step

Record the intended public URL. Write it in full, for example https://cloud.example.net/ or https://example.net/cloud/. Decide whether visitors should use a nonstandard port such as :8443. Do not include a port if the public service uses the standard HTTPS port and the URL does not need to show it.
Find where the redirect repeats. Open the URL in a private browser window, or clear site cookies and try again. In browser developer tools, open the Network panel, enable “Preserve log,” reload, and inspect the repeated 301 or 302 responses and their Location headers. Alternatively run curl -IL --max-redirs 10 https://cloud.example.net/, substituting your URL. Note whether the scheme, hostname, port, or path changes on each response.
Check DNS, TLS, and the proxy route. Confirm the hostname resolves to the intended server and the certificate covers that hostname. If a proxy terminates HTTPS and connects to ownCloud over HTTP, confirm it sends the original host and scheme in trusted forwarding headers. A proxy that forwards HTTPS traffic but tells ownCloud the request was HTTP can cause ownCloud to redirect repeatedly.
Back up and inspect config/config.php. On the ownCloud server, make a copy before editing. The file is usually under the ownCloud installation directory. Check overwrite.cli.url, overwritehost, overwriteprotocol, overwritewebroot, and trusted_proxies. These are not all required in every installation; correct only the settings that match your deployment. Use the configuration syntax and quoting already present in the file.
Set the canonical host and protocol where needed. If ownCloud cannot infer the public address correctly, set overwritehost to the public hostname, with a port only when it is part of the public URL. Set overwriteprotocol to https when clients access the site through HTTPS, even if the proxy-to-server connection uses HTTP. Set overwrite.cli.url to the complete public base URL, including the webroot if applicable. Do not set it to an internal hostname unless that is genuinely the user-facing address.
Set the webroot consistently. If users access ownCloud at https://example.net/cloud, the proxy must pass requests to the correct ownCloud location and preserve or correctly remove the /cloud prefix according to its routing configuration. Set overwritewebroot to /cloud only when ownCloud needs that public prefix for generated URLs. For a site served at the domain root, leave it unset or use the deployment’s documented root configuration; do not add an arbitrary slash or installation-directory name.
Trust only the actual proxy addresses. When a reverse proxy is involved, configure trusted_proxies with the proxy’s private IP address or addresses, not a broad public range. Configure the proxy to supply the original client scheme and host using the forwarding headers supported by your setup. Do not trust client-provided forwarding headers from arbitrary internet traffic.
Choose one place to enforce HTTPS and a canonical hostname. A redirect at the proxy or web server is often appropriate, but it must agree with ownCloud’s public URL settings. Avoid rules that alternate between two hostnames, ports, or paths. If TLS ends at a proxy, do not create a rule that redirects every internal HTTP connection to HTTPS unless the proxy-to-server connection and headers are designed for that behavior.
Check the web-server and proxy path rules. Verify that the ownCloud front controller and rewrite rules are active, and that a subdirectory installation is not being redirected both by the proxy and by the web server to conflicting paths. Compare the actual upstream path with the public path. Use the configuration for your server software and deployment rather than copying rewrite rules from an unrelated setup.
Apply changes and test from outside. Save the files, validate the web-server or proxy configuration, then reload or restart the relevant service using its normal procedure. Open the canonical URL in a fresh private window and repeat the header check. Test login, logout, and a page within ownCloud; confirm redirects stay on the same scheme, host, port, and webroot.

Common Mistakes

Setting overwriteprotocol to http because the proxy connects to the backend over HTTP, even though visitors use HTTPS.
Using an internal hostname or backend port in overwritehost or overwrite.cli.url.
Adding /cloud to the public URL while the proxy has already removed or duplicated that prefix.
Trusting every IP address as a proxy, which can make forwarded host or scheme values untrustworthy.
Changing several layers at once without checking response headers, making the source of the loop harder to find.
Editing configuration without a backup, or placing settings outside the PHP configuration array.

Tips

Use one canonical public URL and redirect alternate hostnames to it once, at a clearly chosen layer.
Keep a written map of client-to-proxy and proxy-to-ownCloud scheme, hostname, port, and path.
After each change, inspect the first few Location headers. A loop often becomes obvious when one value alternates.
Review ownCloud and proxy logs at the time of a failed request; they can show whether the request reached ownCloud and which URL it believed it was serving.

Troubleshooting

The loop switches between HTTP and HTTPS: Check whether the proxy sends the original scheme and whether ownCloud trusts that proxy. Set the public protocol to HTTPS where required, and remove conflicting HTTPS redirects from another layer.

The hostname changes on each redirect: Compare the configured public host with the browser’s hostname, DNS name, and proxy virtual host. Correct the mismatch, including any unintended internal hostname or port.

The path gains or loses /cloud: Trace the path at the proxy and backend. Decide whether the proxy preserves the prefix or strips it, then make ownCloud’s webroot and generated base URL match that arrangement. Avoid applying the prefix twice.

The browser still loops after a correction: Test with curl or a private window to rule out cached redirects and cookies. Confirm the edited file is the active configuration, check for duplicate settings, and inspect proxy and web-server logs. Restore the backup if the service becomes unavailable, then make one controlled change at a time.

Only some pages or command-line links are wrong: Check overwrite.cli.url and any separate virtual-host or subdirectory settings. A browser may work while background jobs generate links from an incorrect base URL.

Frequently Asked Questions

Should I set overwriteprotocol to HTTPS behind a proxy?
Usually, if users connect over HTTPS and the proxy connects to ownCloud over HTTP. Also make sure ownCloud trusts the proxy and receives accurate forwarded scheme information.

What should overwritehost contain?
The public hostname users enter, with a port only if that port is part of the public address. Do not use the backend’s private hostname merely because the proxy connects to it.

When should I use overwritewebroot?
When ownCloud is publicly served beneath a path such as /cloud and it cannot infer that prefix correctly. Its value must match the public path, not the server’s filesystem directory.

Can I fix the loop by clearing cookies?
Clearing cookies can rule out stale session data, but it will not fix conflicting redirects. Check response headers and server settings if the loop returns.

Is it safe to set trusted_proxies to 0.0.0.0/0?
No. Trust only the known proxy addresses or narrow private ranges that actually apply. Broad trust can allow untrusted requests to influence forwarded URL information.

Do I need to restart ownCloud after editing its configuration?
PHP configuration changes usually take effect on a later request, but proxy or web-server changes may need a reload. Validate and reload the service whose configuration you changed.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.