Nginx with Ubuntu and Rails on Digital Ocean - ruby-on-rails

I am trying to get nginx to work with a rails app, but nginx wont start after installation and changing its config file.
Here is the output its giving me:
nginx: [emerg] could not build the types_hash, you should increase either types_hash_max_size: 1024 or types_hash_bucket_size: 32
nginx: configuration file /etc/nginx/nginx.conf test failed
And here is my nginx.conf file:
# This is example contains the bare mininum to get nginx going with
# Unicorn or Rainbows! servers. Generally these configuration settings
# are applicable to other HTTP application servers (and not just Ruby
# ones), so if you have one working well for proxying another app
# server, feel free to continue using it.
#
# The only setting we feel strongly about is the fail_timeout=0
# directive in the "upstream" block. max_fails=0 also has the same
# effect as fail_timeout=0 for current versions of nginx and may be
# used in its place.
#
# Users are strongly encouraged to refer to nginx documentation for more
# details and search for other example configs.
# you generally only need one nginx worker unless you're serving
# large amounts of static files which require blocking disk reads
worker_processes 1;
# # drop privileges, root is needed on most systems for binding to port 80
# # (or anything < 1024). Capability-based security may be available for
# # your system and worth checking out so you won't need to be root to
# # start nginx to bind on 80
user nobody nogroup; # for systems with a "nogroup"
# user nobody nobody; # for systems with "nobody" as a group instead
# Feel free to change all paths to suite your needs here, of course
pid /path/to/nginx.pid;
error_log /path/to/nginx.error.log;
events {
worker_connections 1024; # increase if you have lots of clients
accept_mutex off; # "on" if nginx worker_processes > 1
# use epoll; # enable for Linux 2.6+
# use kqueue; # enable for FreeBSD, OSX
}
http {
# nginx will find this file in the config directory set at nginx build time
include mime.types;
# fallback in case we can't determine a type
default_type application/octet-stream;
# click tracking!
access_log /path/to/nginx.access.log combined;
# you generally want to serve static files with nginx since neither
# Unicorn nor Rainbows! is optimized for it at the moment
sendfile on;
tcp_nopush on; # off may be better for *some* Comet/long-poll stuff
tcp_nodelay off; # on may be better for some Comet/long-poll stuff
# we haven't checked to see if Rack::Deflate on the app server is
# faster or not than doing compression via nginx. It's easier
# to configure it all in one place here for static files and also
# to disable gzip for clients who don't get gzip/deflate right.
# There are other gzip settings that may be needed used to deal with
# bad clients out there, see http://wiki.nginx.org/NginxHttpGzipModule
gzip on;
gzip_http_version 1.0;
gzip_proxied any;
gzip_min_length 500;
gzip_disable "MSIE [1-6]\.";
gzip_types text/plain text/xml text/css
text/comma-separated-values
text/javascript application/x-javascript
application/atom+xml;
# this can be any application server, not just Unicorn/Rainbows!
upstream app_server {
# fail_timeout=0 means we always retry an upstream even if it failed
# to return a good HTTP response (in case the Unicorn master nukes a
# single worker for timing out).
# for UNIX domain socket setups:
server unix:/home/portfolio/tmp/.unicorn.sock fail_timeout=0;
# for TCP setups, point these to your backend servers
# server 192.168.0.7:8080 fail_timeout=0;
# server 192.168.0.8:8080 fail_timeout=0;
# server 192.168.0.9:8080 fail_timeout=0;
}
server {
# enable one of the following if you're on Linux or FreeBSD
listen 80 default deferred; # for Linux
# listen 80 default accept_filter=httpready; # for FreeBSD
# If you have IPv6, you'll likely want to have two separate listeners.
# One on IPv4 only (the default), and another on IPv6 only instead
# of a single dual-stack listener. A dual-stack listener will make
# for ugly IPv4 addresses in $remote_addr (e.g ":ffff:10.0.0.1"
# instead of just "10.0.0.1") and potentially trigger bugs in
# some software.
# listen [::]:80 ipv6only=on; # deferred or accept_filter recommended
client_max_body_size 4G;
server_name _;
# ~2 seconds is often enough for most folks to parse HTML/CSS and
# retrieve needed images/icons/frames, connections are cheap in
# nginx so increasing this is generally safe...
keepalive_timeout 5;
# path for static files
root /var/www/portfolio/public;
# Prefer to serve static files directly from nginx to avoid unnecessary
# data copies from the application server.
#
# try_files directive appeared in in nginx 0.7.27 and has stabilized
# over time. Older versions of nginx (e.g. 0.6.x) requires
# "if (!-f $request_filename)" which was less efficient:
# http://bogomips.org/unicorn.git/tree/examples/nginx.conf?id=v3.3.1#n127
try_files $uri/index.html $uri.html $uri #app;
location #app {
# an HTTP header important enough to have its own Wikipedia entry:
# http://en.wikipedia.org/wiki/X-Forwarded-For
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
# enable this if you forward HTTPS traffic to unicorn,
# this helps Rack set the proper URL scheme for doing redirects:
# proxy_set_header X-Forwarded-Proto $scheme;
# pass the Host: header from the client right along so redirects
# can be set properly within the Rack application
proxy_set_header Host $http_host;
# we don't want nginx trying to do something clever with
# redirects, we set the Host: header above already.
proxy_redirect off;
# set "proxy_buffering off" *only* for Rainbows! when doing
# Comet/long-poll/streaming. It's also safe to set if you're using
# only serving fast clients with Unicorn + nginx, but not slow
# clients. You normally want nginx to buffer responses to slow
# clients, even with Rails 3.1 streaming because otherwise a slow
# client can become a bottleneck of Unicorn.
#
# The Rack application may also set "X-Accel-Buffering (yes|no)"
# in the response headers do disable/enable buffering on a
# per-response basis.
# proxy_buffering off;
proxy_pass http://app_server;
}
# Rails error pages
error_page 500 502 503 504 /500.html;
location = /500.html {
root /var/www/portfolio/public;
}
}
}
types_hash_max_size: 2048;
types_hash_bucket_size: 64;

I made another droplet with digital ocean with nginx already installed and just looked at the nginx.conf file and they had this in there http section
types_hash_max_size 2048;

Related

How to use nginx(intsalled on docker) reverse proxy gitlab(installed on docker too)

I installed gitlab according to the official documentation.
sudo docker run --detach \
--hostname git.stupidpz.com \
--publish 8443:443 --publish 880:80 --publish 822:22 \
--name gitlab \
--restart always \
--volume $GITLAB_HOME/config:/etc/gitlab \
--volume $GITLAB_HOME/logs:/var/log/gitlab \
--volume $GITLAB_HOME/data:/var/opt/gitlab \
--shm-size 256m \
gitlab/gitlab-ee:latest
Now I want to use Nginx(installed By Myself) to reverse proxy gitlab instead of the nginx that comes with the gitlab container.
According to official documentation I added some code in gitlab.rb
# Define the external url
external_url 'http://git.stupidpz.com'
# Disable the built-in nginx
nginx['enable'] = false
# Disable the built-in puma
puma['enable'] = false
# Set the internal API URL
gitlab_rails['internal_api_url'] = 'http://git.stupidpz.com'
# Define the web server process user (ubuntu/nginx)
web_server['external_users'] = ['nginx']
Then gitlab cannot be accessed, I found some error logs in this file /var/log/gitblab/gitlab_workhorse/current
{"correlation_id":"","duration_ms":0,"error":"badgateway: failed to receive response: dial tcp 127.0.0.1:8080: connect: connection refused","level":"error","method":"GET","msg":"","time":"2023-01-25T20:57:21Z","uri":""}
{"correlation_id":"","duration_ms":0,"error":"badgateway: failed to receive response: dial tcp 127.0.0.1:8080: connect: connection refused","level":"error","method":"GET","msg":"","time":"2023-01-25T20:57:31Z","uri":""}
{"correlation_id":"","duration_ms":0,"error":"badgateway: failed to receive response: dial tcp 127.0.0.1:8080: connect: connection refused","level":"error","method":"GET","msg":"","time":"2023-01-25T20:57:41Z","uri":""}
{"correlation_id":"","duration_ms":0,"error":"badgateway: failed to receive response: dial tcp 127.0.0.1:8080: connect: connection refused","level":"error","method":"GET","msg":"","time":"2023-01-25T20:57:51Z","uri":""}
Did nothing else except for adding some code in gitlab.rb.
I wonder where this dial tcp 127.0.0.1:8080 comes from?
I hope you can help me, or give me a correct demo.Many thanks.This problem has been bothering me for two days
Now i figure out why i could not make it works,I mixed up Using an existing Passenger/NGINX installation and Using a non-bundled web-server
If you just need to use your own nginx to proxy gitlab(both of them was installed on docker)
you just need to add two lines to gitlab.rb.
# Disable the built-in nginx
nginx['enable'] = false
# Define the web server process user (ubuntu/nginx)
web_server['external_users'] = ['nginx']
and here is nginx's conf
upstream gitlab-workhorse {
server unix://var/opt/gitlab/gitlab-workhorse/sockets/socket fail_timeout=0;
}
server {
listen *:80;
server_name git.example.com;
server_tokens off;
root /opt/gitlab/embedded/service/gitlab-rails/public;
client_max_body_size 250m;
access_log /var/log/gitlab/nginx/gitlab_access.log;
error_log /var/log/gitlab/nginx/gitlab_error.log;
# Ensure Passenger uses the bundled Ruby version
passenger_ruby /opt/gitlab/embedded/bin/ruby;
# Correct the $PATH variable to included packaged executables
passenger_env_var PATH "/opt/gitlab/bin:/opt/gitlab/embedded/bin:/usr/local/bin:/usr/bin:/bin";
# Make sure Passenger runs as the correct user and group to
# prevent permission issues
passenger_user git;
passenger_group git;
# Enable Passenger & keep at least one instance running at all times
passenger_enabled on;
passenger_min_instances 1;
location ~ ^/[\w\.-]+/[\w\.-]+/(info/refs|git-upload-pack|git-receive-pack)$ {
# 'Error' 418 is a hack to re-use the #gitlab-workhorse block
error_page 418 = #gitlab-workhorse;
return 418;
}
location ~ ^/[\w\.-]+/[\w\.-]+/repository/archive {
# 'Error' 418 is a hack to re-use the #gitlab-workhorse block
error_page 418 = #gitlab-workhorse;
return 418;
}
location ~ ^/api/v3/projects/.*/repository/archive {
# 'Error' 418 is a hack to re-use the #gitlab-workhorse block
error_page 418 = #gitlab-workhorse;
return 418;
}
# Build artifacts should be submitted to this location
location ~ ^/[\w\.-]+/[\w\.-]+/builds/download {
client_max_body_size 0;
# 'Error' 418 is a hack to re-use the #gitlab-workhorse block
error_page 418 = #gitlab-workhorse;
return 418;
}
# Build artifacts should be submitted to this location
location ~ /ci/api/v1/builds/[0-9]+/artifacts {
client_max_body_size 0;
# 'Error' 418 is a hack to re-use the #gitlab-workhorse block
error_page 418 = #gitlab-workhorse;
return 418;
}
# Build artifacts should be submitted to this location
location ~ /api/v4/jobs/[0-9]+/artifacts {
client_max_body_size 0;
# 'Error' 418 is a hack to re-use the #gitlab-workhorse block
error_page 418 = #gitlab-workhorse;
return 418;
}
# For protocol upgrades from HTTP/1.0 to HTTP/1.1 we need to provide Host header if its missing
if ($http_host = "") {
# use one of values defined in server_name
set $http_host_with_default "git.example.com";
}
if ($http_host != "") {
set $http_host_with_default $http_host;
}
location #gitlab-workhorse {
## https://github.com/gitlabhq/gitlabhq/issues/694
## Some requests take more than 30 seconds.
proxy_read_timeout 3600;
proxy_connect_timeout 300;
proxy_redirect off;
# Do not buffer Git HTTP responses
proxy_buffering off;
proxy_set_header Host $http_host_with_default;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://gitlab-workhorse;
## The following settings only work with NGINX 1.7.11 or newer
#
## Pass chunked request bodies to gitlab-workhorse as-is
# proxy_request_buffering off;
# proxy_http_version 1.1;
}
## Enable gzip compression as per rails guide:
## http://guides.rubyonrails.org/asset_pipeline.html#gzip-compression
## WARNING: If you are using relative urls remove the block below
## See config/application.rb under "Relative url support" for the list of
## other files that need to be changed for relative url support
location ~ ^/(assets)/ {
root /opt/gitlab/embedded/service/gitlab-rails/public;
gzip_static on; # to serve pre-gzipped version
expires max;
add_header Cache-Control public;
}
## To access Grafana
location /-/grafana/ {
proxy_pass http://localhost:3000/;
}
error_page 502 /502.html;
}
last but not least,you need to add another bash to your nginx's container,
-v /var/opt/gitlab:/var/opt/gitlab
This will let your nginx container connect to gitlab container.Otherwise you will get "cannot find var/opt/gitlab/gitlab-workhorse/sockets/socket".
It looks like you are installing a GitLab instance as a custom git server on a remote host. There are 3 pieces of this that must work.
DNS setup, remote host's ports and firewall setup.
Working installation of GitLab on the remote host.
Valid SSL certificates, and a correct nginx config for HTTPS.
The first step really depends on your virtual machine and container's setup, but essentially, make sure it (the VM or container) has a public port that responds to requests.
These variables must be set in the remote host's environment as such
--volume $GITLAB_HOME/config:/etc/gitlab
--volume $GITLAB_HOME/logs:/var/log/gitlab
--volume $GITLAB_HOME/data:/var/opt/gitlab \
The above URL covers all the GitLab install steps once you have signed in and verified that it was installed correctly and that it runs as expected on that remote host.
Only then, install and configure nginx. Since GitLab likely will transfer credentials and other secure data, you will need to setup https on nginx.
An example of an Nginx configuration can be found here. There is also a tool by Mozilla that makes building a custom nginx config easier, found here.
The error you show has this URL "127.0.0.1:8080". It is likely you have supplied this URL to the gitlab.rb config somewhere, and that might be a mistake. I cannot be sure without the whole config file however.
Also, it is likely the GitLab image will need to run its own nginx instance, so that the said container when launched may do its job and act as a git server. To reverse proxy this GitLab instance, you may need to install nginx onto your host machine and point it to GitLab Image's nginx.
You may be able to do away with the second nginx instance by appending a new server {} block into the Gitlab Image's nginx config. I would not recommend this.

Ruby on Rails, nginx and unicorn "The page you were looking for doesn't exist"

I recently set up my private little server with nginx and unicorn to get into the backend stuff with Ruby on Rails.
To test things out I just made a little scaffold app, which seems to be working fine.
But, from time to time after I refresh the site I get an 404 Error
This error can be forced to appear if I refresh the site very often in short periods (e.g. hitting F5 10x times as fast as possible)
Is this some standard DDOS protection?
I couldn't find anything in the logs (neither in unicorn nor the nginx logs).
Here are my configs:
nginx App config
upstream app {
# Path to Unicorn SOCK file, as defined previously
server unix:/home/ruby/app/shared/sockets/unicorn.sock fail_timeout=0;
}
server {
listen 80;
server_name munichmetal.de app.munichmetal.de;
root /home/ruby/app/public;
try_files $uri/index.html $uri #app;
location #app {
proxy_pass http://app;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
}
error_page 500 502 503 504 /500.html;
client_max_body_size 4G;
keepalive_timeout 10;
}
unicorn config
# set path to application
app_dir = File.expand_path("../..", __FILE__)
shared_dir = "#{app_dir}/shared"
working_directory app_dir
# Set unicorn options
worker_processes 5
preload_app true
timeout 30
# Set up socket location
listen "#{shared_dir}/sockets/unicorn.sock", :backlog => 64
# Logging
stderr_path "#{shared_dir}/log/unicorn.stderr.log"
stdout_path "#{shared_dir}/log/unicorn.stdout.log"
# Set master PID location
pid "#{shared_dir}/pids/unicorn.pid"
I can also provide the logs if needed.
My first guess was that with the convention over configuration paradigm there might be some sort of built-in DDOS protection in unicorn, but I couldn't find anything.
So any tipps in pointing me in the right direction would be great.
Thanks,
Alex

nginx tries to serve .rss/.json itself rather than letting rails/unicorn serve it

My rails app runs perfectly fine in production using nginx and unicorn except for one thing:
Requesting /articles.rss and /articles.json leads to a 404 with an error in the nginx logs that the requested file doesn't exist. Requesting e.g. /articles?format=rss works. So it looks like the .rss leads nginx to think this is a static file rather than dynamically generated content. In development (using the builtin server of rails) this works fine.
I use the h5bp config files for nginx, here's my site configuration (domain name replaced):
# www to non-www redirect -- duplicate content is BAD:
# https://github.com/h5bp/html5-boilerplate/blob/5370479476dceae7cc3ea105946536d6bc0ee468/.htaccess#L362
# Choose between www and non-www, listen on the *wrong* one and redirect to
# the right one -- http://wiki.nginx.org/Pitfalls#Server_Name
upstream app {
server unix:/var/www/rails-cms/shared/tmp/sockets/rails-cms.unicorn.sock fail_timeout=0;
}
server {
# don't forget to tell on which port this server listens
listen [::]:80;
listen 80;
# listen on the www host
server_name www.<my domain>;
# and redirect to the non-www host (declared below)
return 301 $scheme://<my domain>$request_uri;
}
server {
# listen [::]:80 accept_filter=httpready; # for FreeBSD
# listen 80 accept_filter=httpready; # for FreeBSD
# listen [::]:80 deferred; # for Linux
# listen 80 deferred; # for Linux
listen [::]:80;
listen 80;
# The host name to respond to
server_name <my domain>;
# Path for static files
root /var/www/rails-cms/current/public;
try_files $uri/index.html $uri #app;
location #app {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_pass http://app;
}
#Specify a charset
charset utf-8;
# Custom 404 page
error_page 404 /404.html;
# Include the basic h5bp config set
include h5bp/basic.conf;
}
This occurs because you include h5bp/basic.conf file which in turn includes h5bp/location/expires.conf file. Take a look at the latter file's contents:
# cache.appcache, your document html and data
location ~* \.(?:manifest|appcache|html?|xml|json)$ {
expires -1;
access_log logs/static.log;
}
# Feed
location ~* \.(?:rss|atom)$ {
expires 1h;
add_header Cache-Control "public";
}
See? the first location intercepts .json requests, and the second one - .rss requests, so your app never catches these requests.
If you want your app to handle these requests, you should either refuse h5bp at all, or just comment out abovementioned locations.
In both cases your app should send cache headers itself, if you want it of course.
Edit:
But since your json and rss contents are dynamically generated, I would not recommend using cache headers.

Using unicorn and nginx for ruby 2.0.0 based rails application

I have been trying to configure unicorn and nginx to run my ruby 2.0.0 on rails 3.2.13 to run e-commerce application. I have been trying lot of the examples and blog and trying it out, but I am not to configure the unicorn and nginx. I am pasting nginx and unicorn files here. Kindly have a look into it. Initially I used to get 500 error now I am getting 400 bad request error.
unicorn.rb
root = "/home/ubuntu/apps/new_spree_st"
working_directory root
pid "#{root}/tmp/pids/unicorn.pid"
stderr_path "#{root}/log/unicorn_stderr.log"
stdout_path "#{root}/log/unicorn_stdout.log"
listen "/tmp/unicorn.new_spree_st.sock"
worker_processes 4
timeout 30
# Force the bundler gemfile environment variable to
# reference the capistrano "current" symlink
before_exec do |_|
ENV["BUNDLE_GEMFILE"] = File.join(root, 'Gemfile')
end
nginx.conf
# This is example contains the bare mininum to get nginx going with Unicorn or Rainbows! servers. Generally these configuration settings are
# applicable to other HTTP application servers (and not just Ruby ones), so if you have one working well for proxying another app server, feel
# free to continue using it.
#
# The only setting we feel strongly about is the fail_timeout=0
# directive in the "upstream" block. max_fails=0 also has the same
# effect as fail_timeout=0 for current versions of nginx and may be
# used in its place.
#
# Users are strongly encouraged to refer to nginx documentation for more
# details and search for other example configs.
# you generally only need one nginx worker unless you're serving
# large amounts of static files which require blocking disk reads
#worker_connections 4096;
worker_processes 4;
# # drop privileges, root is needed on most systems for binding to port 80
# # (or anything < 1024). Capability-based security may be available for
# # your system and worth checking out so you won't need to be root to
# # start nginx to bind on 80
#user nobody nogroup; # for systems with a "nogroup"
# user nobody nobody; # for systems with "nobody" as a group instead
# Feel free to change all paths to suite your needs here, of course
pid /etc/nginx/nginx.pid;
error_log /var/log/nginx/nginx.error.log;
events {
worker_connections 4024; # increase if you have lots of clients
accept_mutex off; # "on" if nginx worker_processes > 1
# use epoll; # enable for Linux 2.6+
# use kqueue; # enable for FreeBSD, OSX
}
http {
# nginx will find this file in the config directory set at nginx build time
include mime.types;
# fallback in case we can't determine a type
default_type application/octet-stream;
# click tracking!
access_log /var/log/nginx/nginx.access.log combined;
# you generally want to serve static files with nginx since neither
# Unicorn nor Rainbows! is optimized for it at the moment
sendfile on;
tcp_nopush on; # off may be better for *some* Comet/long-poll stuff
tcp_nodelay off; # on may be better for some Comet/long-poll stuff
# we haven't checked to see if Rack::Deflate on the app server is
# faster or not than doing compression via nginx. It's easier
# to configure it all in one place here for static files and also
# to disable gzip for clients who don't get gzip/deflate right.
# There are other gzip settings that may be needed used to deal with
# bad clients out there, see http://wiki.nginx.org/NginxHttpGzipModule
gzip on;
gzip_http_version 1.0;
gzip_proxied any;
gzip_min_length 500;
gzip_disable "MSIE [1-6]\.";
gzip_types text/plain text/html text/xml text/css
text/comma-separated-values
text/javascript application/x-javascript
application/atom+xml;
# this can be any application server, not just Unicorn/Rainbows!
upstream app_server {
# fail_timeout=0 means we always retry an upstream even if it failed
# to return a good HTTP response (in case the Unicorn master nukes a
# single worker for timing out).
# for UNIX domain socket setups:
server 127.0.0.1:80 fail_timeout=0;
# for TCP setups, point these to your backend servers
# server 192.168.0.7:8080 fail_timeout=0;
# server 192.168.0.8:8080 fail_timeout=0;
# server 192.168.0.9:8080 fail_timeout=0;
}
server {
# enable one of the following if you're on Linux or FreeBSD
# listen 80 default deferred; # for Linux
# listen 80 default accept_filter=httpready; # for FreeBSD
# If you have IPv6, you'll likely want to have two separate listeners.
# One on IPv4 only (the default), and another on IPv6 only instead
# of a single dual-stack listener. A dual-stack listener will make
# for ugly IPv4 addresses in $remote_addr (e.g ":ffff:10.0.0.1"
# instead of just "10.0.0.1") and potentially trigger bugs in
# some software.
# listen [::]:80 ipv6only=on; # deferred or accept_filter recommended
client_max_body_size 4G;
server_name _;
# ~2 seconds is often enough for most folks to parse HTML/CSS and
# retrieve needed images/icons/frames, connections are cheap in
# nginx so increasing this is generally safe...
keepalive_timeout 5;
# path for static files
root /home/ubuntu/apps/new_spree_st/public;
# Prefer to serve static files directly from nginx to avoid unnecessary
# data copies from the application server.
#
# try_files directive appeared in in nginx 0.7.27 and has stabilized
# over time. Older versions of nginx (e.g. 0.6.x) requires
# "if (!-f $request_filename)" which was less efficient:
# http://bogomips.org/unicorn.git/tree/examples/nginx.conf?id=v3.3.1#n127
try_files $uri/index.html $uri.html $uri #app;
location #app {
# an HTTP header important enough to have its own Wikipedia entry:
# http://en.wikipedia.org/wiki/X-Forwarded-For
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
# enable this if you forward HTTPS traffic to unicorn,
# this helps Rack set the proper URL scheme for doing redirects:
# proxy_set_header X-Forwarded-Proto $scheme;
# pass the Host: header from the client right along so redirects
# can be set properly within the Rack application
proxy_set_header Host $http_host;
# we don't want nginx trying to do something clever with
# redirects, we set the Host: header above already.
proxy_redirect off;
# set "proxy_buffering off" *only* for Rainbows! when doing
# Comet/long-poll/streaming. It's also safe to set if you're using
# only serving fast clients with Unicorn + nginx, but not slow
# clients. You normally want nginx to buffer responses to slow
# clients, even with Rails 3.1 streaming because otherwise a slow
# client can become a bottleneck of Unicorn.
#
# The Rack application may also set "X-Accel-Buffering (yes|no)"
# in the response headers do disable/enable buffering on a
# per-response basis.
# proxy_buffering off;
proxy_pass http://app_server;
}
# Rails error pages
error_page 500 502 503 504 /500.html;
location = /500.html {
root /home/ubuntu/apps/new_spree_st/public;
}
}
}
Your unicorn process is listening on a socket, however your app_server directive for Nginx is directing traffic to TCP port 80 (which assuming Nginx is running on port 80, is just redirecting traffic back to itself in an endless loop).
See the sample unicorn nginx config file. Similar to that, your app_server should look like this:
upstream app_server {
server unix:/tmp/unicorn.new_spree_st.sock fail_timeout=0;
}

uwsgi invalid request block size

I am running uwsgi in emperor mode
uwsgi --emperor /path/to/vassals/ --buffer-size=32768
and getting this error
invalid request block size: 21327 (max 4096)...skip
What to do? I also tried -b 32768.
I aslo ran into same issue while following some tutorial.
The problem was that I set the option socket = 0.0.0.0:8000 instead of http = 0.0.0.0:8000.
socket option intended to be used with some third-party router (nginx for instance), while when http option is set uwsgi can accept incoming HTTP requests and route them by itself.
The correct solution is not to switch to HTTP protocol. You just need to increase the buffer size in uWSGI settings.
buffer-size=32768
or in commandline mode:
-b 32768
Quote from official documentation:
By default uWSGI allocates a very small buffer (4096 bytes) for the headers of each request. If you start receiving “invalid request block size” in your logs, it could mean you need a bigger buffer. Increase it (up to 65535) with the buffer-size option.
If you receive ‘21573’ as the request block size in your logs, it could mean you are using the HTTP protocol to speak with an instance speaking the uwsgi protocol. Don’t do this.
From here: https://uwsgi-docs.readthedocs.io/en/latest/ThingsToKnow.html
I could fix it adding --protocol=http to the uwsgi.
I ran into the same issue trying to run it under nginx and was following the
docs here. It is important to note that once you switch to nginx you have to make sure you are not trying to access the app on the port specified by the --socket param but rather the "listen" port in nginx.conf. Although your problem is described differently the title matches exactly the issue I had.
This error is shown when uWSGI server is using uwsgi protocol and one tries to access it via http protocol by curl or web browser directly. If you can, try configuring your uWSGI server to use http protocol, so you can access it via web browser or curl.
In case you cannot (or do not want to) change it, you can use a reverse proxy (e.g. nginx) in front of local or remote uWSGI server, see https://uwsgi-docs.readthedocs.org/en/latest/Nginx.html
If it feels like too much work, give a try to uwsgi-tools python package:
$ pip install uwsgi-tools
$ uwsgi_curl 10.0.0.1:3030
There is also a simple reverse proxy server uwsgi_proxy if you need to access your application(s) via web browser etc. See more expanded answer https://stackoverflow.com/a/32893520/179581
As pointed out in another comment from the docs:
If you receive ‘21573’ as the request block size in your logs, it could mean you are using the HTTP protocol to speak with an instance speaking the uwsgi protocol. Don’t do this.
If you are using Nginx, this will occur if you are have this configuration (or something similarly odd):
proxy_pass http://unix:/path/to/socket.sock
this is speaking HTTP to uWSGI (which makes it grumpy). Instead, use:
uwsgi_pass unix:/path/to/socket.sock;
man i m havin same issue;
so i did it ...
look using UWSGI + DJANGO + NGINX + REACT +
1 - nano /etc/uwsgi/sites/app_plataform.ini [uwsgi]
DJANGO_SETTINGS_MODULE = app_plataform.settings env =
DJANGO_SETTINGS_MODULE settings.configure()
chdir = /home/app_plataform home = /root/app_plataform
module = prometheus_plataform.wsgi:application
master = true processes = 33 buffer-size=32768
socket = /home/app_plataform/app_plataform.sock
chmod-socket = 777 vacuum = true
2 - make a serious performance upgrade on nginx ... user www-data;
worker_processes auto; worker_processes 4; pid /run/nginx.pid; include /etc/nginx/modules-enabled/*.conf;
events { worker_connections 4092; multi_accept on; }
http { ##UPGRADE CONFIGS
client_body_buffer_size 16K; client_header_buffer_size 16k;
client_max_body_size 32m; #large_client_header_buffers 2 1k;
client_body_timeout 12; client_header_timeout 12; keepalive_timeout
15; send_timeout 10; access_log off;
## # Basic Settings ##
sendfile on; tcp_nopush on; tcp_nodelay on; #keepalive_timeout 65;
types_hash_max_size 2048; server_tokens off;
server_names_hash_bucket_size 64; # server_name_in_redirect off;
include /etc/nginx/mime.types; default_type
application/octet-stream;
## # SSL Settings ##
ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
ssl_prefer_server_ciphers on;
## # Logging Settings ##
access_log /var/log/nginx/access.log; error_log
/var/log/nginx/error.log;
## # Gzip Settings ##
gzip on; gzip_comp_level 2; gzip_min_length 1000; gzip_proxied
expired no-cache no-store private auth; gzip_types text/plain
application/x-javascript text/xml text/css application/xml; gzip_vary
on;
#gzip_proxied any; #gzip_comp_level 6; gzip_buffers 16 8k;
gzip_http_version 1.1; #gzip_types text/plain text/css
application/json application/javascript text/xml application/xml
application/xml+rss text/javascript;
## # Virtual Host Configs ##
include /etc/nginx/conf.d/.conf; include
/etc/nginx/sites-enabled/; }
3 - then ... restart services or reebot server ...
systemctl restart uwsgi & systemctl restart nginx
for this particular error invalid request block size: 21327 (max 4096)...skip
it depends on where you're running your solution either on a local machine or a remote server(AWS......).
this solution worked for me as I shrugged with this working on my local machine and as well within a docker container
1 -- change from socket = :8000 in your ini file to http= :8000
and this would work perfectly within docker as well
You can increase the buffer size in uWSGI settings.
The quick solution would be, Remove cookies from the browser for that URL.
Open developer tools in browser > Go to Application tab and > remove cookies associated with the URL.

Resources