Permalink & NGINX not playing nice

WordPress is closely tied to a site’s main .htaccess file. Many plugins also make changes to the file. And nginx doesn’t support .htaccess files. So…you would be much better off using Apache. Besides, if you install Apache with mpm_event and use PHP-FPM, its performance can rival nginx.

Of greater concern is your using a home system as a server to the internet. Hopefully you have taken the necessary steps to harden your home system against attacks. In addition, many ISPs prohibit webservers in their terms of service, and if they find out, your home internet service will be terminated. Good luck!

I agree with what @diondesigns said and the data streams of a home Internet account usually work backwards from what a web server really needs.

Shared hosting runs around $3 to $5 a month. Less headaches, a better system all around and you don’t need to worry about running a server 24/7/365. Spend a few dollars to buy less headaches and more time to devote to your core capabilities.

And that dynamic DNS service goes away too.

rnmahler,

Your issue doesn’t appear to be WordPress permalinks. If it were, you would be able to have the site working correctly with WordPress’ default “ugly” URLs. But this is not the case.

See your other post for a suggested fix, if you really want to go this route.

But as others have suggested already, basic hosting is so cheap these days it may not be worth the hassle to host your own server at home, unless you have some very good reason to do so.

WordPress is closely tied to a site’s main .htaccess file. Many plugins also make changes to the file. And nginx doesn’t support .htaccess files. So…you would be much better off using Apache.

This is like saying an iPhone doesn’t have a Google Play store. Sure, it doesn’t… but it has its own marketplace for apps, Apple’s App Store, and doesn’t need a Google Play store to be complete.

Sure .htaccess is Apache’s way of handling configuration changes (including URL rewrites) on a per-directory basis. But Nginx has its own way of doing URL rewriting, and works beautifully for millions of high-traffic WordPress websites. Nginx is also officially supported by WordPress.

The nginx way of URL rewriting requires modifying a system-level configuration file with root-level permissions. This is well beyond the capabilities of most WordPress users. It is why all shared hosting providers, as well as control panels such as cPanel and Plesk, use Apache or Litespeed.

And one look at the Codex page you referenced demonstrates the number of hoops one must jump through in order to use nginx with WordPress. With Apache…WordPress and all its plugins/themes just work. No hoops to jump, no manual editing of system-level files.

Anyway, this is off topic. Let’s hope the OP chooses a hosting solution instead of worrying whether he will be paying thousands of dollars in bandwidth overage charges if a teen hacker decides to hit his home system with a 100Gbps DDoS attack. ??

It is why all shared hosting providers, as well as control panels such as cPanel and Plesk, use Apache or Litespeed.

Very funny… and so NOT true.

How old is Nginx?

And how old are Apache and these control panels?

That’s the real reason Apache is default on “legacy” control panels… Nginx is just so new and was not available for a long time when these control panels were built and were pretty much the only way to manage a hosting account.

I’ve provided Nginx with user-configurable options for my hosting clients (including rewrite rules) within WHM/cPanel control panel for over five years now, and I’m just a little guy with mediocre (at best) sysadmin skills.

And in case you’re not that much clued in the industry or you just missed the memo, cPanel’s next major version will have Nginx baked in.

so lets start with a hosting solution which is not an option for now (cost is not the issues), i have run and tested services in this way for the last 15 years – there are more reasons than i can to go into but unfortunately does not answer the fundamental question – this should be a fairly easy fix (one would hope).

I have tried this with both Apache and NGINX – both clean installs with a similar outcome.

thank you for responding, just want to see this up and running.