Nginx

WordPress を動かすには LAMP スタック ( Linux + Apache + MySQL + PHP ）が人気ですが、 Nginx を使うことも可能です。WordPress は Nginx をサポートしており、WordPress.com のような大規模な WordPress サイトでは Nginx で動作しているものもあります。

Nginx には複数の導入方法があることを知っておきましょう。Nginx は Apacheの前にリバースプロキシとして設定することができ、Nginx のスピードの恩恵を受けながら Apache の全ての機能を利用することができる非常に強力な設定となっています。Nginx をサーバーとして使用していると報告しているほとんどのサイトは（ HTTPレスポンスヘッダーから収集した統計に基づいて）、実際には Nginx をリバースプロキシとして使用していて、サーバには Apache を使用しています。( HTTP レスポンスヘッダに ” Nginx “と表示されているのは、サーバではなくリバースプロキシによって報告されています)

このガイドでは、Apache の代わりに Nginx をプライマリサーバとして使用するスタンドアロンの Nginx の設定について説明しています。Nginx は Apache の完全な代替品ではないことに注意してください。WordPress の実装に影響を与えるいくつかの重要な違いがありますので、先に進む前に知っておく必要があります。

Nginx では、Apache の .htaccess や IIS の web.config ファイルのようなディレクトリレベルの設定ファイルがありません。すべての設定は管理者がサーバーレベルで行う必要があり、Apache や IIS のように WordPress が設定を変更することはできません。
Pretty パーマリンクの機能は、Nginx を実行している場合には若干異なります。
Nginx には .htaccess 型の機能がなく、WordPress ではサーバーの設定を自動で変更することができないため、リライトルールを生成することができません。
インストールを変更しないと、 “index.php” がパーマリンクに追加されてしまいます。(プラグイン(下記参照)や、子テーマの functions.php にカスタムコードを追加することで、これを軽減する方法があります)
しかし、もしあなたがいくつかの（限定的な）.htaccess 機能を持ちたいのであれば、PHP 用のhtscanner PECL 拡張機能をインストールすることで追加することは技術的に可能です。(ただし、これは完全な解決策ではありませんので、本番環境で使用する前に徹底的にテストしてデバッグするようにしてください)

このガイドでは、Nginx のインストールと設定方法については説明しません。
すでに Nginx をインストールしていて、Nginx の操作方法やデバッグ方法を基本的に理解していることを前提としています。

一般的なマルチサイトサポート

WordPress を Nginx で動作させるには、バックエンドの php-cgi を設定する必要があります。設定できるオプションは「fastcgi」か「php-fpm」です。ここでは、php-fpmを使用しています。php-fpmはPHP 5.3+に含まれているため、インストールは簡単です。

Nginxの設定は5つのファイルに分かれており、それぞれのオプションがわかりやすいように丁寧にコメントされています。また、(英語原文の)著者は、nginx のベストプラクティスをフォローしようとするベストエフォート型を作りました。

メインスタートアップファイル

/etc/nginx/nginx.conf ( Arch Linux を使っている場合は /etc/nginx/conf/nginx.conf ) に相当します。

# 一般的なスタートアップファイル
user {user} {group};

#grep processor /proc/cpuinfo | wc -l "コマンドを実行して検索してください。
worker_processes  auto;
worker_cpu_affinity auto;

error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;

# bind() できないというメッセージがログに残らないようにする。
#daemon     off;

events {
	worker_connections  1024;
}

http {
#	rewrite_log on;

	include mime.types;
	default_type       application/octet-stream;
	access_log         /var/log/nginx/access.log;
	sendfile           on;
#	tcp_nopush         on;
	keepalive_timeout  3;
#	tcp_nodelay        on;
#	gzip               on;
        #php max upload limit cannot be larger than this       
	client_max_body_size 13m;
	index              index.php index.html index.htm;

	# PHPへのバックエンド接続を抽象化したアップストリーム
	upstream php {
                #this should match value of "listen" directive in php-fpm pool
		server unix:/tmp/php-fpm.sock;
#		server 127.0.0.1:9000;
	}

	include sites-enabled/*;
}

標準のnginx.confファイルとは少し異なります。この設定は、Ubuntu/Debian の柔軟性を最大限に高めるために有効なサイトを宣言する方法に従っています – ‘sites-available’ を使ってコンフィグを保存し、’sites-enabled’ からコンフィグファイルにシンボリックリンクしています。

サイトごとの設定

# すべてをメインサイトにリダイレクトします。私たちは別のサーバーステートメントを使用しており、if ステートメントを使用していません。
# http://wiki.nginx.org/IfIsEvil を参照してください。


server {
        server_name  _;
        return 302 $scheme://example.com$request_uri;
}

server {
    server_name example.com;
    root /var/www/example.com;

    index index.php;

    include global/restrictions.conf;

    # 追加のルールはこちらに記述する。

    # 以下のうちどれか一つを読み込む。
    include global/wordpress.conf;
#    include global/wordpress-ms-subdir.conf;
#    include global/wordpress-ms-subdomain.conf;
}

設定のセクションを複数のファイルに分割することで、同じロジックを何度も再利用することができます。グローバル」サブディレクトリは、汎用的に使用するための追加ルールを追加するために使用します (nginx のインストール方法に応じて /etc/nginx/conf/global/ または /etc/nginx/global/ のいずれかを使用します)。

一般的な制限設定のファイル

# 一般的な制限設定のファイル
# どの server {} ブロックからもインクルードできるよう設計されています。
location = /favicon.ico {
    log_not_found off;
    access_log off;
}

location = /robots.txt {
    allow all;
    log_not_found off;
    access_log off;
}

# .htaccess, .htpasswd, .DS_Store (Mac)といった隠しファイルへのアクセスを拒否します。
# 後で解析するために (あるいは fail2ban のようなファイアウォールユーティリティに渡すために) リクエストを記録しておきます。
location ~ /\. {
    deny all;
}

# アップロードディレクトリ内の拡張子が .php のファイルへのアクセスを拒否する
# サブディレクトリのインストールやマルチサイトネットワークでも動作します。
# 後で解析するために (あるいは fail2ban のようなファイアウォールユーティリティに渡すために) リクエストを記録しておきます。
location ~* /(?:uploads|files)/.*\.php$ {
    deny all;
}

通常のWordPress のルール

シングルサイトでのインストールのための ‘global/wordpress.conf’ ファイルです。

# WordPress シングルブログルール。
# どの server {} ブロックからもインクルードできるよう設計されています。
# PHPへのバックエンド接続を抽象化したアップストリーム
upstream php {
        server unix:/tmp/php-cgi.socket;
        server 127.0.0.1:9000;
}

server {
        ## サーバーの名前はここに記述します。
        server_name domain.tld;
        ## ルートディレクトリの指定
        root /var/www/wordpress;
        ## これは http ブロックに含まれているはずで、もし含まれていればここでは必要ありません。
        index index.php;

        location = /favicon.ico {
                log_not_found off;
                access_log off;
        }

        location = /robots.txt {
                allow all;
                log_not_found off;
                access_log off;
        }

        location / {
                # 静的なコンテンツのために PHP を実行しないため、これはこれでかっこいいです。
                # デフォルトではないパーマリンクがクエリ文字列を使っても壊れないように、"?$args "の部分をインクルードしています。
                try_files $uri $uri/ /index.php?$args;
        }

        location ~ \.php$ {
                #注意: php.iniに "cgi.fix_pathinfo = 0; "を設定してください。
                include fastcgi.conf;
                fastcgi_intercept_errors on;
                fastcgi_pass php;
        }

        location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
                expires max;
                log_not_found off;
        }
}

これは Nginx 用の最新の例です :
https://www.nginx.com/resources/wiki/start/topics/recipes/wordpress/

WordPress マルチサイトサブディレクトリのルール

マルチサイトのサブディレクトリにインストールする場合は、’ global/wordpress.conf ‘ ファイルを参照してください。

# WordPress マルチサイトのサブディレクトリ用ルール.
# どの server {} ブロックからもインクルードできるよう設計されています。

map $uri $blogname{
    ~^(?P/[^/]+/)files/(.*)       $blogpath ;
}

map $blogname $blogid{
    default -999;

    #参照: https://wordpress.org/extend/plugins/nginx-helper/
    #/var/www/wordpress/wp-content/plugins/nginx-helper/map.conf ファイルをインクルードします ;
}

server {
    server_name example.com ;

    root /var/www/example.com/htdocs;
    index index.php;

    location ~ ^(/[^/]+/)?files/(.+) {
        try_files /wp-content/blogs.dir/$blogid/files/$2 /wp-includes/ms-files.php?file=$2 ;
        access_log off;     log_not_found off; expires max;
    }

    #PHPで readfile() (ファイル出力)を避ける
    location ^~ /blogs.dir {
        internal;
        alias /var/www/example.com/htdocs/wp-content/blogs.dir ;
        access_log off;     log_not_found off; expires max;
    }

    if (!-e $request_filename) {
        rewrite /wp-admin$ $scheme://$host$uri/ permanent;
        rewrite ^(/[^/]+)?(/wp-.*) $2 last;
        rewrite ^(/[^/]+)?(/.*\.php) $2 last;
    }

    location / {
        try_files $uri $uri/ /index.php?$args ;
    }

    location ~ \.php$ {
        try_files $uri =404;
        include fastcgi_params;
        fastcgi_pass php;
    }

    #ここに静的コンテンツのexpiry-headersのルールを追加します。
}

Nginx には2つの特別な機能が用意されています。X-Accel-Redirect と map です。この2つの機能を使用することで、WordPressのマルチサイトネットワーク上での静的ファイル提供のパフォーマンスのヒットをなくすことができます。

WordPressのマルチサイトのサブディレクトリのルール

map $http_host $blogid {
    default       -999;

    #参照: https://wordpress.org/extend/plugins/nginx-helper/
    #/var/www/wordpress/wp-content/plugins/nginx-helper/map.conf ファイルをインクルードします ;

}

server {
    server_name example.com *.example.com ;

    root /var/www/example.com/htdocs;
    index index.php;

    location / {
        try_files $uri $uri/ /index.php?$args ;
    }

    location ~ \.php$ {
        try_files $uri =404;
        include fastcgi_params;
        fastcgi_pass php;
    }

    #WPMU Files
        location ~ ^/files/(.*)$ {
                try_files /wp-content/blogs.dir/$blogid/$uri /wp-includes/ms-files.php?file=$1 ;
                access_log off; log_not_found off;      expires max;
        }

    #WPMU の x-sendfile は php readfile()を避けるために
    location ^~ /blogs.dir {
        internal;
        alias /var/www/example.com/htdocs/wp-content/blogs.dir;
        access_log off;     log_not_found off;      expires max;
    }

    #ここに静的コンテンツのexpiry-headersのルールを追加します。
}

参照: https://www.nginx.com/resources/wiki/start/topics/recipes/wordpress/

Nginx での HTTPS

Nginx でHTTPS を有効にするのは比較的簡単です。

server {
    # 443 で IPv4 と IPv6 の両方をリッスンし、HTTPS と HTTP/2 のサポートを有効にします。
    # HTTP/2 は nginx 1.9.5以上で利用可能です。
    listen *:443 ssl http2;
    listen [::]:443 ssl http2;

    # SSL キーファイルの場所を示します。
    ssl_certificate /srv/www/ssl/ssl.crt;
    ssl_certificate_key /srv/www/ssl/ssl.key;
    ssl_dhparam /srv/www/master/ssl/dhparam.pem;

    # サーバー名称を記述します。
    server_name example.com *.example.com;

    # HSTSを有効にします。これはHSTSを尊重するクライアント（ほとんどの最新ブラウザ）にSSLを強制します。includeSubDomains フラグはオプションです。
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

    # キャッシュ、プロトコル、受け入れられる暗号化方式を設定します。この設定は2015年9月時点でA+ SSL Labsのスコアを獲得しています。
    ssl_session_cache shared:SSL:20m;
    ssl_session_timeout 10m;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;
    ssl_ciphers 'ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:!ADH:!AECDH:!MD5';
}

Mozilla には優れたSSL 設定生成ツールもあります。

WP Super Cache のルール

# WP Super Cache のルール
# 'wordpress-ms-...' からインクルードされるよう設定されています。

set $cache_uri $request_uri;

# クエリ文字列を含む POST リクエストや urls は常に PHP にアクセスしなければなりません。
if ($request_method = POST) {
        set $cache_uri 'null cache';
}

if ($query_string != "") {
        set $cache_uri 'null cache';
}   

# 以下のセグメントを含む uris をキャッシュしないでください。
if ($request_uri ~* "(/wp-admin/|/xmlrpc.php|/wp-(app|cron|login|register|mail).php|wp-.*.php|/feed/|index.php|wp-comments-popup.php|wp-links-opml.php|wp-locations.php|sitemap(_index)?.xml|[a-z0-9_-]+-sitemap([0-9]+)?.xml)") {
        set $cache_uri 'null cache';
}   

# ログインしているユーザーや最近コメントした人にはキャッシュを使わない。
if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_logged_in") {
        set $cache_uri 'null cache';
}

# START MOBILE
# モバイルブラウザのセクションでは、キャッシュされていないバージョンをサーバーに提供しています。

COMMENTED by default as most modern wordpress themes including twenty-eleven are responsive. Uncomment config lines in this section if you want to use a plugin like WP-Touch
# if ($http_x_wap_profile) {
#        set $cache_uri 'null cache';
#}

#if ($http_profile) {
#        set $cache_uri 'null cache';
#}

#if ($http_user_agent ~* (2.0\ MMP|240x320|400X240|AvantGo|BlackBerry|Blazer|Cellphone|Danger|DoCoMo|Elaine/3.0|EudoraWeb|Googlebot-Mobile|hiptop|IEMobile|KYOCERA/WX310K|LG/U990|MIDP-2.|MMEF20|MOT-V|NetFront|Newt|Nintendo\ Wii|Nitro|Nokia|Opera\ Mini|Palm|PlayStation\ Portable|portalmmm|Proxinet|ProxiNet|SHARP-TQ-GX10|SHG-i900|Small|SonyEricsson|Symbian\ OS|SymbianOS|TS21i-10|UP.Browser|UP.Link|webOS|Windows\ CE|WinWAP|YahooSeeker/M1A1-R2D2|iPhone|iPod|Android|BlackBerry9530|LG-TU915\ Obigo|LGE\ VX|webOS|Nokia5800)) {
 #       set $cache_uri 'null cache';
#}

#if ($http_user_agent ~* (w3c\ |w3c-|acs-|alav|alca|amoi|audi|avan|benq|bird|blac|blaz|brew|cell|cldc|cmd-|dang|doco|eric|hipt|htc_|inno|ipaq|ipod|jigs|kddi|keji|leno|lg-c|lg-d|lg-g|lge-|lg/u|maui|maxo|midp|mits|mmef|mobi|mot-|moto|mwbp|nec-|newt|noki|palm|pana|pant|phil|play|port|prox|qwap|sage|sams|sany|sch-|sec-|send|seri|sgh-|shar|sie-|siem|smal|smar|sony|sph-|symb|t-mo|teli|tim-|tosh|tsm-|upg1|upsi|vk-v|voda|wap-|wapa|wapi|wapp|wapr|webc|winw|winw|xda\ |xda-)) {
  #      set $cache_uri 'null cache';
#}
#END MOBILE

# 存在する場合はキャッシュされたファイルを使用し、そうでない場合は WordPress にリクエストを渡す。
location / {
        try_files /wp-content/cache/supercache/$http_host/$cache_uri/index.html $uri $uri/ /index.php?$args ;
}

実験的な調整:

HTTPS を使用している場合、最新の WP Super Cache の開発版では、HTTP とHTTPS を区別するために異なるディレクトリ構造を使用している可能性があります。 try_files の行は以下のようになっているかもしれません。

location / {
        try_files /wp-content/cache/supercache/$http_host/$cache_uri/index-https.html $uri $uri/ /index.php?$args ;
}

W3 Total Cache のルール

W3 Total Cache では、WordPressの構成によってディスクベースのキャッシュストレージのディレクトリ構造を使い分けています。

キャッシュのバリデーションチェックは、以下のように共通して行われます。

# W3TC ブラウザキャッシュ 
set $cache_uri $request_uri;

# クエリ文字列を含む POST リクエストや urls は常に PHP にアクセスしなければなりません。
if ($request_method = POST) {
        set $cache_uri 'null cache';
}   
if ($query_string != "") {
        set $cache_uri 'null cache';
}   

# 以下のセグメントを含む uris をキャッシュしないでください。
if ($request_uri ~* "(/wp-admin/|/xmlrpc.php|/wp-(app|cron|login|register|mail).php|wp-.*.php|/feed/|index.php|wp-comments-popup.php|wp-links-opml.php|wp-locations.php|sitemap(_index)?.xml|[a-z0-9_-]+-sitemap([0-9]+)?.xml)") {
        set $cache_uri 'null cache';
}   

# ログインしているユーザーや最近コメントした人にはキャッシュを使わない。
if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_logged_in") {
        set $cache_uri 'null cache';
}
#ADD mobile rules from WP SUPER CACHE section above

#APPEND A CODE BLOCK FROM BELOW...

通常の WordPress (マルチサイトなし)
以下を使用してください:

# Use cached or actual file if they exists, otherwise pass request to WordPress
location / {
        try_files /wp-content/w3tc/pgcache/$cache_uri/_index.html $uri $uri/ /index.php?$args ;
}

サブディレクトリを持つマルチサイト
以下を使用してください:

if ( $request_uri ~* "^/([_0-9a-zA-Z-]+)/.*" ){
        set $blog $1;
}

set $blog "${blog}.";

if ( $blog = "blog." ){
        set $blog "";
}

# 存在する場合はキャッシュされたファイルを使用し、そうでない場合は WordPress にリクエストを渡す。
location / {
        try_files /wp-content/w3tc-$blog$host/pgcache$cache_uri/_index.html $uri $uri/ /index.php?$args ;
}

サブドメイン/ドメインマッピングのあるマルチサイト
以下を使用してください:

location / {
        try_files /wp-content/w3tc-$host/pgcache/$cache_uri/_index.html $uri $uri/ /index.php?$args;
}

注意事項

Nginx は gzip とブラウザキャッシュを自動的に処理することができるので、その部分は Nginx に任せた方が良いでしょう。
W3 Total Cache Minify ルールは上記の設定で問題なく動作します。

Nginx fastcgi_cache

Nginx は、サーバーの負荷を軽減するために、独自にキャッシュを実行することができます。Nginx の組み込みの fastcgi_cache を使いたい場合は、fastcgi_cache_purge モジュールを使って Nginx をコンパイルしてください。これにより、ページが編集された際にキャッシュをパージしてくれるようになります。WordPress 側では、fastcgi_cache_purge 機能を利用するために、Nginx Helper のようなプラグインをインストールする必要があります。

設定は以下のようになります:

http{…} block 、外部サーバー{…}block に Nginx キャッシュゾーンを定義する

#move next 3 lines to /etc/nginx/nginx.conf if you want to use fastcgi_cache across many sites 
fastcgi_cache_path /var/run/nginx-cache levels=1:2 keys_zone=WORDPRESS:500m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
fastcgi_cache_use_stale error timeout invalid_header http_500;

WordPress のサイト設定では、server{…}block に以下のようにキャッシュチェックブロックを追加します:

#fastcgi_cache 開始
set $no_cache 0;

# クエリ文字列を含む POST リクエストや urls は常に PHP にアクセスしなければなりません。
if ($request_method = POST) {
        set $no_cache 1;
}   
if ($query_string != "") {
        set $no_cache 1;
}   

# 以下のセグメントを含む uris をキャッシュしないでください。
if ($request_uri ~* "(/wp-admin/|/xmlrpc.php|/wp-(app|cron|login|register|mail).php|wp-.*.php|/feed/|index.php|wp-comments-popup.php|wp-links-opml.php|wp-locations.php|sitemap(_index)?.xml|[a-z0-9_-]+-sitemap([0-9]+)?.xml)") {
        set $no_cache 1;
}   

# ログインしているユーザーや最近コメントした人にはキャッシュを使わない。
if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in") {
        set $no_cache 1;
}

その後、PHP の処理ブロックに変更を加えます。

これを以下の php ブロックに追加してください。fastcgi_cache_valid 200 60m;という行に注意してください。この行は、nginx に200レスポンス(通常のページ)のみをキャッシュするように指示しています。これは多言語サイトにおいて重要です。もし実装されていない場合、nginx はユーザーを言語に応じてそれぞれのコンテンツにリダイレクトさせる代わりに、1つの言語でメインURL をキャッシュしてしまいます。

         fastcgi_cache_bypass $no_cache;
         fastcgi_no_cache $no_cache;

         fastcgi_cache WORDPRESS;
         fastcgi_cache_valid 200 60m;

このように、以下のようになります。

location ~ [^/]\.php(/|$) {
    fastcgi_split_path_info ^(.+?\.php)(/.*)$;
    if (!-f $document_root$fastcgi_script_name) {
        return 404;
    }
    # This is a robust solution for path info security issue and works with "cgi.fix_pathinfo = 1" in /etc/php.ini (default)

    include fastcgi.conf;
    fastcgi_index index.php;
#    fastcgi_intercept_errors on;
    fastcgi_pass php;

    fastcgi_cache_bypass $no_cache;
    fastcgi_no_cache $no_cache;

    fastcgi_cache WORDPRESS;
    fastcgi_cache_valid 200 60m;
}

最後に条件付きパージの場所を追加します。

location ~ /purge(/.*) {
        # Uncomment the following two lines to allow purge only from the webserver
        #allow 127.0.0.1;
    #deny all;

        fastcgi_cache_purge WORDPRESS "$scheme$request_method$host$1";
}

もし ‘unknown directive “fastcgi_cache_purge”‘ というエラーが出た場合は、Nginx に fastcgi_cache_purge モジュールがインストールされているかどうかを確認してください。

マルチサイトでもう少しパフォーマンスを

デフォルトでは、マルチサイトの設定では、静的ファイルのリクエストにより、phpが表示されます（ ms-files.php ファイル）。Nginx Map{…} directive を使用することで、より良いパフォーマンスを得ることができます。

Nginxの設定では、server{…}block の上に以下のようなセクションを追加します。

map $http_host $blogid {
    default               0;

    example.com           1;
    site1.example.com     2;
    site1.com             2;
}

これは、サイト名とブログID のリストです。このようなサイト名とブログIDのペアのリストを取得するには、Nginx Helper を使用することができます。このプラグインは map.conf ファイルも生成してくれるので、以下のように map{} section に直接インクルードすることができます:

map $http_host $blogid {
    default               0;

    include /path/to/map.conf ;
}

map{…}section を作成した後、Nginx の設定をもう一つ変更するだけで、/files/ へのリクエストは最初に nginx map{…} を使って処理されます。

location ~ ^/files/(.*)$ {
          try_files /wp-content/blogs.dir/$blogid/$uri /wp-includes/ms-files.php?file=$1 ;
          access_log off; log_not_found off; expires max;
 }

注釈

新しいサイトが作成されたり、削除されたり、既存のサイトに追加ドメインがマッピングされたりすると、Nginx Helper は自動的に map.conf ファイルを更新しますが、Nginx の設定を手動でリロードする必要があります。これは後でいつでも可能です。それまでは、新規サイト用のファイルのみが php-fpm で提供されます。
この方法ではシンボリックリンクは生成されません。そのため、シンボリックリンクの後に誤って削除してしまったり、バックアップスクリプトを実行してしまっても問題ありません。
大規模なネットワークでは、単一の map.conf ファイルが存在するので、これはうまくスケールアップできるでしょう。

注釈

最後に重要な注意点をいくつか挙げておきます。この全体の設定は、サイトのルートがブログであり、参照されるすべてのファイルがホスト上に存在することを前提としています。ブログを /blog のようなサブディレクトリに置く場合、ルールを変更する必要があります。おそらく、誰かがこれらのルールを取って、例えば:

set $wp_subdir "/blog";

ディレクティブをメインの ‘sever’ ブロックに置いて、その場でWordPressのルールを生成するような

Warning

Global restrictions file のタイプミスは抜け穴を作る可能性があります。アップロード “ディレクトリが本当に保護されているかどうかをテストするには、いくつかのコンテンツを含むPHPファイルを作成してください(例. )を作成し、それを “uploads “ディレクトリ(またはそのサブディレクトリの一つ)にアップロードし、ブラウザからアクセス(実行)してみてください。

リソース

リファレンス

nginx + php-fpm + PHP APC + WordPress multisite (subdirectory) + WP Super Cache (Thanks bigsite)
Notes on removing ‘index.php’ from Permalinks (Can be done using Nginx Helper Plugin)

外部リンク

スクリプトとツール

For WordPress Nginx scripted installation CentminMod can be used for CentOS.

カテゴリー

翻訳・改善にご協力ください