{"id":21602,"date":"2025-03-20T11:36:47","date_gmt":"2025-03-20T10:36:47","guid":{"rendered":"https:\/\/contabo.com\/blog\/?p=21602"},"modified":"2025-03-20T11:36:56","modified_gmt":"2025-03-20T10:36:56","slug":"nginx-configuration-beginners-guide","status":"publish","type":"post","link":"https:\/\/contabo.com\/blog\/nginx-configuration-beginners-guide\/","title":{"rendered":"NGINX Configuration Beginner\u2019s Guide"},"content":{"rendered":"\n
\"NGINX<\/figure>\n\n\n\n

NGINX is a powerful web server that also doubles as a reverse proxy and load balancer. It\u2019s often chosen by those who want faster page loads and reliable traffic handling. This guide breaks down the basics of NGINX server configuration, giving you a roadmap for hosting everything from personal portfolios to high-traffic applications.<\/p>\n\n\n\n

You\u2019ll see how to configure NGINX with directives, HTTP blocks, server blocks, and location blocks. Each piece matters in its own way. By understanding these core elements, you\u2019ll be able to create a well-structured NGINX server configuration that\u2019s easy to maintain. If you\u2019re new to NGINX, expect to pick up best practices along the way.<\/p>\n\n\n\n

Wondering how to serve multiple domains or optimize performance? Curious about using location blocks for specific paths or files? By the time you finish, you\u2019ll have a clear idea of how to make NGINX work in your favor. Let\u2019s get started.<\/p>\n\n\n\n

What Is NGINX?<\/h3>\n\n\n\n

What does NGINX do? NGINX is open-source software designed to handle large numbers of concurrent connections without dragging its feet. It manages everything from static file delivery to load balancing for busy websites. Many people label it a NGINX web server, but it also functions as a NGINX reverse proxy, which is handy when you need to shield back-end services from direct public access.<\/p>\n\n\n\n

Apache has been a traditional choice for web hosting, but it processes requests in a more process-driven way. That approach can become heavy with spiking traffic. By contrast, NGINX uses an event-driven design to serve more clients with fewer resources. This often results in better performance and lower memory usage.<\/p>\n\n\n\n

You\u2019ll see it used by small businesses, big brands, and folks who run streaming services. Why? Because it\u2019s flexible. For example, you can offload SSL processing to NGINX and pass unencrypted traffic to back-end servers. You can also distribute incoming requests to multiple servers behind the scenes. <\/p>\n\n\n\n

Essentially, what is NGINX? It\u2019s an engine that tackles concurrency at scale, serves static files efficiently, and smoothly manages complex workloads.<\/p>\n\n\n\n

NGINX Directives<\/h3>\n\n\n\n

NGINX relies on directives to do its job. Each directive is like an instruction that tells the server how to behave. You’ll typically find them in the NGINX configuration file, usually at \/etc\/nginx\/nginx.conf<\/code> on many Linux distributions. The exact location may vary depending on your distribution (Ubuntu, CentOS, Arch Linux, etc.) and installation method. Directives look like directive_name value;<\/code> and always end with a semicolon.<\/p>\n\n\n\n

You\u2019ll see NGINX configuration directives in different contexts. Some reside in the main (global) scope, which applies across the entire server. Others belong in the http<\/code> block, the server<\/code> block, or the location<\/code> block. A few NGINX global directives define user permissions or worker processes, giving you a broad framework. Here\u2019s a small example:<\/p>\n\n\n\n

user nginx;\nworker_processes auto;\npid \/run\/nginx.pid;<\/code><\/pre>\n\n\n\n
Those lines clarify who\u2019s running NGINX, how many worker processes should start, and where to store the PID file. Below these, you\u2019ll often see http { ... }<\/code> for HTTP-specific settings.<\/p>\n\n\n\n
Inside http<\/code>, you may add directives for compression, caching, or logging. Then you\u2019ll have server and location blocks for domain-specific or path-specific instructions. The nesting matters. If you put something in the http<\/code> block, it\u2019s shared by every server block unless overridden at a lower level. Keeping track of this hierarchy will help you organize your files with fewer errors.<\/p>\n\n\n\n
HTTP Block<\/h3>\n\n\n\n
In most setups, the NGINX HTTP block exists in the main nginx.conf<\/code> or a file that\u2019s pulled in with an include<\/code> statement. This block decides how HTTP traffic is handled before your server or location blocks refine the details.<\/p>\n\n\n\n
Typical directives in this section might set the default content type, manage connection timeouts, or turn on file compression. For example:<\/p>\n\n\n\n
http {\n    include       mime.types;\n    default_type  application\/octet-stream;\n\n    sendfile       on;\n    keepalive_timeout  65;\n}<\/code><\/pre>\n\n\n\n
Here, include mime.types;<\/code> helps NGINX figure out file types (like .html<\/code> and .css<\/code>). The sendfile on;<\/code> directive uses an OS-based mechanism to streamline file transfers. If you want to enable gzip, you\u2019d do it here too.<\/p>\n\n\n\n
Think of this as a broad canvas. Any setting defined in the HTTP block applies globally, unless a deeper block or directive overrides it.<\/p>\n\n\n\n
Server Blocks<\/h3>\n\n\n\n
If you plan to host multiple sites on a single NGINX instance, NGINX server blocks are your friend. Each block defines how a particular site or domain behaves. At a basic level, a server block might look like this:<\/p>\n\n\n\n
server {\n    listen 80;\n    server_name example.com www.example.com;\n\n    root \/var\/www\/example;\n    index index.html;\n\n    location \/ {\n        try_files $uri $uri\/ =404;\n    }\n}<\/code><\/pre>\n\n\n\n
Here, you specify the port (listen 80;<\/code>) and the domain names. You also decide where your site\u2019s files live. This is often called \u201cvirtual hosting.\u201d You can place multiple server blocks in one file or split them across separate files that NGINX includes. Changes not showing up? See the FAQs<\/a> for tips.<\/p>\n\n\n\n
SSL? No problem. Just use listen 443 ssl;<\/code> with your certificate and key settings inside the same block. You\u2019ll also have location blocks for different URLs, letting you fine-tune your site\u2019s structure. For instance, you might forward requests to a back-end application at \/api\/<\/code> while serving static files under \/<\/code>.<\/p>\n\n\n\n
Server blocks keep each site neatly contained, making it straightforward to manage multiple domains on the same physical or virtual server.<\/p>\n\n\n\n
Location Blocks<\/h3>\n\n\n\n
Within a server block, NGINX location blocks spell out how certain paths or file patterns are treated. You might use them to serve images, forward PHP requests to a fastcgi process, or even deny access to hidden files. For example:<\/p>\n\n\n\n
location \/images\/ {\n    alias \/var\/data\/images\/;\n}\n\nlocation ~ \\.php$ {\n    fastcgi_pass unix:\/run\/php\/php7.4-fpm.sock;\n    include fastcgi_params;\n}<\/code><\/pre>\n\n\n\n
The first location hands off everything under \/images\/<\/code> to a directory at \/var\/data\/images\/<\/code>. The second uses a regular expression (~ \\.php$<\/code>) to match .php<\/code> files and pass them to a PHP-FPM socket.<\/p>\n\n\n\n
NGINX uses a priority system for location blocks. Exact matches (like location = \/hello.html<\/code>) beat more general ones. Regex-based matches can override, too, if specified with the right flags. Nested locations let you go deeper if you must tweak behavior for subpaths.<\/p>\n\n\n\n
NGINX follows a specific order when matching location blocks:<\/p>\n\n\n\n
    \n
  1. Exact match (=): location = \/path<\/code><\/li>\n\n\n\n
  2. Preferential prefix match (^~): location ^~ \/path<\/code><\/li>\n\n\n\n
  3. Regular expression match (~, ~*): location ~ \\.php$<\/code><\/li>\n\n\n\n
  4. Prefix match: location \/path<\/code><\/li>\n<\/ol>\n\n\n\n
    NGINX first checks for exact matches. If none exist, it remembers the longest prefix match and then checks regex matches. If a regex matches, NGINX uses that location; otherwise, it uses the stored prefix match. Understanding this priority system helps prevent unexpected behavior in your configuration.<\/p>\n\n\n\n
    Not sure which location block is in effect? You can check the overall config by running nginx -T<\/code>, then scanning for your domain and path. Also, consider using nginx -t<\/code> to confirm you\u2019ve got the syntax right before reloading.<\/p>\n\n\n\n
    Using Location Root and Index<\/h3>\n\n\n\n
    Sometimes you\u2019ll see a NGINX location directive with root<\/code> or alias<\/code>. This tells NGINX where to find actual files. For instance:<\/p>\n\n\n\n
    location \/ {\n    root \/var\/www\/mywebsite;\n    index index.html index.htm;\n}<\/code><\/pre>\n\n\n\n
    When someone visits your domain, NGINX looks in \/var\/www\/mywebsite<\/code> for index.html<\/code> or index.htm<\/code>. If neither exists, you might set a custom error page or rely on the default 404.<\/p>\n\n\n\n
    alias<\/code> is slightly different from root<\/code>. With alias<\/code>, the path you specify replaces the entire request path. With root<\/code>, NGINX appends the request URI to the directory path. Either approach works if you plan carefully. Just be sure you understand how the files line up, so requests map correctly to the underlying filesystem.<\/p>\n\n\n\n
    This straightforward arrangement helps you avoid headaches. If you see unexpected 404s, double-check which directive you used and confirm your file paths match reality. See the FAQs<\/a> for more information.<\/p>\n\n\n\n
    Listening Ports<\/h3>\n\n\n\n
    By default, NGINX listens on port 80 for HTTP and port 443 for HTTPS. That\u2019s defined with the NGINX listen directive. For example:<\/p>\n\n\n\n
    server {\n    listen 80;\n    server_name mysite.org;\n    ...\n}<\/code><\/pre>\n\n\n\n
    You can also enable more than one NGINX listen port:<\/p>\n\n\n\n
    listen 80;\nlisten 8080;<\/code><\/pre>\n\n\n\n
    If you have multiple network interfaces, you might specify an IP with:<\/p>\n\n\n\n
    listen 192.168.1.10:80;<\/code><\/pre>\n\n\n\n
    Remember to adjust your firewall rules so traffic to these ports isn\u2019t blocked. That way, visitors can reach your content no matter which port they\u2019re using.<\/p>\n\n\n\n
    Server_name Directive<\/h3>\n\n\n\n
    The NGINX server name directive tells a server block which domain(s) or subdomains it should handle:<\/p>\n\n\n\n
    server_name example.org www.example.org;<\/code><\/pre>\n\n\n\n
    This block will respond to requests for either domain. Wildcards are also allowed:<\/p>\n\n\n\n
    server_name *.example.net;<\/code><\/pre>\n\n\n\n
    That matches any subdomain. You can even go more advanced and use regex, though that\u2019s less common. For example:<\/p>\n\n\n\n
    server_name ~^(?<subdom>.+)\\.example\\.com$;<\/code><\/pre>\n\n\n\n
    Keep your setup clear. If you have many subdomains, a wildcard often simplifies things. Always confirm that DNS settings direct traffic to your server\u2019s IP address.<\/p>\n\n\n\n
    NGINX Reverse Proxy<\/h3>\n\n\n\n
    A NGINX reverse proxy works by receiving traffic and passing it to another service. This can reduce direct exposure of your back-end app and let NGINX handle SSL or rate limiting. A basic NGINX reverse proxy config might look like this:<\/p>\n\n\n\n
    server {\n    listen 80;\n    server_name proxydemo.com;\n\n    location \/ {\n        proxy_pass http:\/\/127.0.0.1:4000\/;\n        proxy_set_header Host $host;\n        proxy_set_header X-Real-IP $remote_addr;\n    }\n}<\/code><\/pre>\n\n\n\n
    In this NGINX reverse proxy example, incoming traffic to proxydemo.com<\/code> gets forwarded to http:\/\/127.0.0.1:4000\/<\/code>. The extra headers help the target app see the original host and IP address. If you need load balancing, you can define multiple servers:<\/p>\n\n\n\n
    upstream myapp {\n    server 192.168.1.50:4000;\n    server 192.168.1.51:4000;\n}\n\nserver {\n    listen 80;\n    server_name balancedsite.com;\n\n    location \/ {\n        proxy_pass http:\/\/myapp;\n    }\n}<\/code><\/pre>\n\n\n\n
    When setting up load balancing, remember to place any keepalive directive after your load-balancing algorithm:<\/p>\n\n\n\n
    upstream myapp {
    server 192.168.1.50:4000;
    server 192.168.1.51:4000;
    least_conn; # Load balancing algorithm
    keepalive 32; # Keepalive connections
    }<\/code><\/pre>\n\n\n\n
    This NGINX reverse proxy setup distributes requests across the servers listed in upstream<\/code>, improving performance and availability. This is a simple way to handle scaling without rewriting your core application.<\/p>\n\n\n\n
    NGINX Configuration FAQ<\/h3>\n\n\n\n
    Why aren\u2019t my changes showing up?<\/strong>
    NGINX only loads its config on startup or after a reload. So after editing, run sudo systemctl reload nginx<\/code> or sudo nginx -s reload<\/code>.<\/p>\n\n\n\n
    How do I see if my NGINX configuration is valid?<\/strong>
    Use nginx -t<\/code> to test for NGINX config errors. If something\u2019s wrong, it\u2019ll pinpoint the file and line number.<\/p>\n\n\n\n
    Why do my static files return 404?<\/strong>
    Check your root<\/code> or alias<\/code> paths. A single typo or mismatch between location blocks and directories can lead to missing files.<\/p>\n\n\n\n
    How do I improve speed?<\/strong>
    Turn on sendfile<\/code>, try gzip on;<\/code> for compression, and set sensible timeouts. For huge traffic, consider load balancing or caching layers.<\/p>\n\n\n\n
    Can I test without risking downtime?<\/strong>
    It\u2019s best to have a staging environment. If that isn\u2019t possible, apply changes gradually and keep an eye on logs. That way, you catch any problems quickly.<\/p>\n\n\n\n
    Custom NGINX Configurations on Contabo Servers<\/h3>\n\n\n\n
    When you run NGINX on servers from Contabo, you\u2019ll find a strong platform that can handle different workloads. If you\u2019re on a budget and need flexibility, try a VPS plan<\/a> with enough RAM and SSD storage to support your apps. Once you\u2019ve spun up the server, installing NGINX is straightforward:<\/p>\n\n\n\n
    sudo apt update\nsudo apt install nginx<\/code><\/pre>\n\n\n\n
    Then check its status:<\/p>\n\n\n\n
    sudo systemctl status nginx<\/code><\/pre>\n\n\n\n
    You can fine-tune your config based on the resources you have. For example, if you\u2019re hosting a Node.js application, you\u2019d likely use a reverse proxy setup to offload SSL connections. If you\u2019re running PHP, you might enable fastcgi and create specific location blocks. Keep an eye on memory and CPU usage. When traffic grows, you might scale up to a bigger plan or add more servers to share the load.<\/p>\n\n\n\n
    Custom NGINX Setup Using Hosting Panels<\/h3>\n\n\n\n
    Hosting panels like cPanel, Plesk, or Webmin can simplify your cPanel NGINX, Plesk NGINX, or Webmin NGINX configurations. For cPanel, there are add-ons that let you manage NGINX through a user-friendly interface. You can check out our cPanel VPS offerings<\/a> if you prefer that environment.<\/p>\n\n\n\n
    Meanwhile, Plesk servers<\/a> have built-in NGINX support. You can run Apache and NGINX together or rely on NGINX alone. In Webmin, you\u2019ll see a dedicated NGINX module for creating virtual hosts, setting up SSL, or customizing directives. All of these panels aim to make your job easier.<\/p>\n\n\n\n
    Conclusion<\/h3>\n\n\n\n
    NGINX offers a flexible way to serve content, manage load balancing, and handle reverse proxies. You\u2019ve learned about directives, HTTP blocks, server blocks, location blocks, and how they connect to form a solid NGINX configuration. You\u2019ve also explored listening ports, domain settings, and the benefits of a reverse proxy setup.<\/p>\n\n\n\n
    If you\u2019re eager to keep going, there\u2019s a world of NGINX performance tuning tips to discover. Try enabling caching or fine-tuning worker processes to get the most out of your hardware. By putting these basics into practice, you\u2019ll build a stable environment for nearly any project that comes your way.<\/p>\n\n\n\n
    <\/p>\n","protected":false},"excerpt":{"rendered":"
    New to NGINX? This comprehensive guide breaks down the essentials of NGINX configuration, from basic directives to advanced reverse proxy setups. Discover how to structure your config files, serve multiple domains, and optimize performance – all explained in straightforward terms with practical examples you can implement on your Contabo server.<\/p>\n","protected":false},"author":63,"featured_media":21628,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"_uag_custom_page_level_css":"","site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"set","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[18],"tags":[187,1976,1980,1977,570,1983,1974,1975,1979,1982,1981,912,1754],"ppma_author":[1492],"class_list":["post-21602","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-tutorials","tag-contabo-vps","tag-http-blocks","tag-load-balancing","tag-location-blocks","tag-nginx","tag-proxy_pass","tag-reverse-proxy","tag-server-blocks","tag-server_name","tag-ssl-configuration","tag-virtual-hosting","tag-web-hosting","tag-web-server"],"uagb_featured_image_src":{"full":["https:\/\/contabo.com\/blog\/wp-content\/uploads\/2025\/03\/blog-head_nginx-config_En.jpg",1200,630,false],"thumbnail":["https:\/\/contabo.com\/blog\/wp-content\/uploads\/2025\/03\/blog-head_nginx-config_En-150x150.jpg",150,150,true],"medium":["https:\/\/contabo.com\/blog\/wp-content\/uploads\/2025\/03\/blog-head_nginx-config_En-600x315.jpg",600,315,true],"medium_large":["https:\/\/contabo.com\/blog\/wp-content\/uploads\/2025\/03\/blog-head_nginx-config_En-768x403.jpg",768,403,true],"large":["https:\/\/contabo.com\/blog\/wp-content\/uploads\/2025\/03\/blog-head_nginx-config_En.jpg",1200,630,false],"1536x1536":["https:\/\/contabo.com\/blog\/wp-content\/uploads\/2025\/03\/blog-head_nginx-config_En.jpg",1200,630,false],"2048x2048":["https:\/\/contabo.com\/blog\/wp-content\/uploads\/2025\/03\/blog-head_nginx-config_En.jpg",1200,630,false]},"uagb_author_info":{"display_name":"Christopher Carter","author_link":"https:\/\/contabo.com\/blog\/author\/christophercarter\/"},"uagb_comment_info":0,"uagb_excerpt":"New to NGINX? This comprehensive guide breaks down the essentials of NGINX configuration, from basic directives to advanced reverse proxy setups. Discover how to structure your config files, serve multiple domains, and optimize performance - all explained in straightforward terms with practical examples you can implement on your Contabo server.","authors":[{"term_id":1492,"user_id":63,"is_guest":0,"slug":"christophercarter","display_name":"Christopher Carter","avatar_url":"https:\/\/secure.gravatar.com\/avatar\/63db81672a5ce4c1e8ee39753d00251d561b5b3a9967febf1c4f662024cef00f?s=96&d=mm&r=g","0":null,"1":"","2":"","3":"","4":"","5":"","6":"","7":"","8":""}],"_links":{"self":[{"href":"https:\/\/contabo.com\/blog\/wp-json\/wp\/v2\/posts\/21602","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/contabo.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/contabo.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/contabo.com\/blog\/wp-json\/wp\/v2\/users\/63"}],"replies":[{"embeddable":true,"href":"https:\/\/contabo.com\/blog\/wp-json\/wp\/v2\/comments?post=21602"}],"version-history":[{"count":13,"href":"https:\/\/contabo.com\/blog\/wp-json\/wp\/v2\/posts\/21602\/revisions"}],"predecessor-version":[{"id":22692,"href":"https:\/\/contabo.com\/blog\/wp-json\/wp\/v2\/posts\/21602\/revisions\/22692"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/contabo.com\/blog\/wp-json\/wp\/v2\/media\/21628"}],"wp:attachment":[{"href":"https:\/\/contabo.com\/blog\/wp-json\/wp\/v2\/media?parent=21602"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/contabo.com\/blog\/wp-json\/wp\/v2\/categories?post=21602"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/contabo.com\/blog\/wp-json\/wp\/v2\/tags?post=21602"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/contabo.com\/blog\/wp-json\/wp\/v2\/ppma_author?post=21602"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}