Fix XenForo thread URLs that return 404 after enabling friendly URLs or moving the forum to another subdirectory.
Symptoms: what this problem looks like
- The forum index loads but /threads/ and /forums/ routes return 404.
- The error starts after enabling friendly URLs or moving the forum from / to /forum/.
- Legacy index.php routes work while cleaner routes fail.
Why it happens
- Apache rewrite rules are missing or AllowOverride does not apply.
- An Nginx location block does not route unresolved paths to XenForo’s entry point.
- Rewrite rules still target the old /xf/ or /forum/ install directory.
- A reverse proxy or WordPress installation owns an overlapping URL prefix.
Before making changes
Capture the original error and its exact time. Work on an authorized system, keep sensitive details out of public logs, and preserve a restorable configuration or data backup whenever a change could affect production.
- Record whether Apache, Nginx or a combined proxy stack serves the site.
- Find the real XenForo public root and installation subdirectory.
- Compare one failing friendly URL with the XenForo generated URL and existing redirects.
Choose Beginner for low-risk recovery checks or Advanced for environment-specific commands and evidence-based changes. Always confirm the underlying cause. Record an affected forum thread URL and whether the XenForo homepage loads. Keep the friendly URL setting unchanged while collecting evidence. Apache .htaccess edits will not fix routing handled exclusively by Nginx. Find the effective virtual host and any proxy routing layers. Verify whether the forum is installed at the document root or in /forum/. Ensure the front controller path matches that location. Use XenForo’s official web server instructions, validate the configuration, then test a forum, thread, static asset and admin route. The following is an illustrative /forum/ route, not a complete secure Nginx server configuration. Adapt to your XenForo version, installation root and protected locations. On self-managed Nginx, validate syntax and the correct server block before any reload; hosting panels may generate additional rules. Do not copy unverified old-version examples into a modern XenForo/WordPress stack; protect internal_data and confirm WordPress URLs continue to route properly.
Step-by-Step Troubleshooting
Confirm the site still has an index route
Identify the web server
Check path-specific rewrite configuration
Apply and test a scoped rewrite rule
Inspect an Nginx front-controller pattern
location /forum/ { try_files $uri $uri/ /forum/index.php?$uri&$args;}Verify the active server configuration
nginx -tPreserve protected directories and other applications
Common mistakes to avoid
- Do not assume copying .htaccess will fix Nginx.
- Do not remove a WordPress front controller without mapping both applications.
- Do not issue permanent redirects until old and new XenForo routes have been tested.
How to verify the fix
Retest the original failing path or operation, not only a generic homepage or status code. Compare the result against your pre-change evidence and observe the system long enough to rule out a temporary recovery.
- Forum index, thread, member and admin URLs all resolve correctly.
- Static assets load and protected directories remain unavailable to anonymous users.
- Old bookmarked routes redirect safely if their URLs changed.
Solution Checklist
If the error continues: rollback and escalation
Restore the previous server routing configuration and temporarily disable friendly URLs if supported until a validated path-specific rule is deployed.
If you need vendor or hosting support, share the software version, exact time, affected route, sanitized error and the single change already attempted. Never include passwords, private tokens, raw session cookies or personal data.
Prevent this issue from returning
- Document actual install paths in infrastructure configuration.
- Smoke-test all critical XenForo routes after moves and web server changes.
Further reading
Consult the official or primary technical documentation for your exact software version before changing production settings.
This troubleshooting guide presents possible causes and safe diagnostic steps. Product versions, hosting restrictions and deployment procedures vary; a recognized symptom is not a confirmed root cause.