nginx
(多くは)リバースプロキシーとして使う
server{} の中で、listen, server_name, locationを設定する
Dockerで稼働してるportにproxy_passする形。 headerを転送してやらないと、host名などがlocalhostや127.0.0.1に残ってしまうので、気をつける
話は細かいので、よく読めてないが、、
chmod 701 user_home
centos の version7だが、普通に userを作ったが、/home/shirai の権限は 700だった。 これで 403だし
systemdのunitファイルでnginx(www-data)での実行では user_home(shirai)に cd(change directory)もできなかった。 今日やったエラー。
upstreamを serverブロックに書いた。httpブロックの中。
locationの設定が重複。同じ条件を複数ファイルで記述したせいかな。(pleskの設定めんどい...) upstream が 500 error時の対応
教訓
ブロック構造を意識しよう。
locationの記述は、？？となるけど、ゆっくり考えれば（たぶん）ok.
非常に詳しい
以下、単語だけみて、ある程度イメージ湧けばOK.
user, worker_process, worker_rlimit_nofile, error_log, pid eventsブロック
worker_connections, multi_accept, use の３つ
httpブロック
server_tokens, default_type, include
log_format( main, ltsv), access_log, charset,
send_file, tcp_nppush, tcp_nodelay
keepalive_timeout(75), keepalive_requests
set_real_ip_from, real_ip_header(X-Forwarded-For)
client_header_timeout, client_body_timeout
limit_conn, limit_conn_zone (同時接続数制限、DDOS攻撃対策)
proxyは以下(リバースプロキシ用)
proxy_buffering_on, proxy_buffer_size, proxy_buffers, proxy_cache_path
listen, バーチャルホストの設定は別ブロックなので。
upstream
unicornなどのバックエンドサーバーを使用する時にupstreamでsocketを指定する
proxy_pass, proxy_set_header
server (バーチャルホストの設定用に)
listen, server_name, root
rewrite
satisfy, auth_basic
try_files
location 'path'
stub_state, allow, deny
exipires, add_header
break, internal
イメージつかむには
cache
locationの書き方
prefixの意味を確認して、（なしなら前方一致)
この評価の順番は以下のようになります。
前方一致で、正規表現.。前方一致の中でも、最も一致した条件（条件が詳細ということかな)
@は、回答でいくと、@で変数のlocationを作っておいて、
try_files $uri @変数;1 fallout的なlocationとしてうけてる。 #uri トラブル対処
会社
Nginx incという会社が開発者によって作られていて商用版があったが、
Licence