Paano Mag-Host ng Maramihang Website sa Nginx Server Blocks (Virtual Hosts)

Ang Nginx server blocks ay ang virtual host na konsepto na nagbibigay-daan para mag-publish ng higit sa isang domain o website gamit ang isang Nginx installation. Halimbawa, sa isang VPS, maaari mong i-set up ang example.com, blog.example.com, at pangalawang-site.com na may kanya-kanyang root directory, log files, SSL certificates, at PHP settings. Sa madaling salita, para gawing maayos ang setup: gumawa ng hiwalay na folder para sa bawat site, i-configure ang DNS records papunta sa IP ng server, maglagay ng hiwalay na server block sa /etc/nginx/sites-available, mag-link papunta sa sites-enabled, mag-test ng configuration, at i-reload ang Nginx service.

Sa gabay na ito, tatalakayin natin ang proseso ng multi-site hosting gamit ang Nginx server blocks na akma para sa production server. Ang layunin ay hindi lang gumana ang setup, kundi gawing manageable, secure, mabilis, backup-friendly, at scalable ang iyong environment. May practical na tips para sa web agency, developer, e-commerce owners, mga negosyo na may maramihang brand, at system admin na nagpapalakad ng maraming proyekto sa iisang server. Kung wala ka pang server, para sa resource selection, bisitahin ang VPS server at para sa domain management, tingnan ang Pagrehistro ng Domain.

Ano ang Nginx Server Blocks?

Ang Nginx server blocks ay mga configuration na tinatawag na server block sa loob ng Nginx, at nagdedesisyon kung aling site ang tutugunan base sa HTTP o HTTPS request. Katulad ito ng VirtualHost sa Apache. Kapag nag-type ang bisita sa browser ng isang domain, i-resolve ng DNS ito papunta sa IP ng server. Pagkatapos, titingnan ni Nginx ang Host header sa request at tatakbuhin ang server block na tumutugma sa server_name.

Dahil dito, posibleng mag-host ng marami at iba-ibang website sa iisang IP at server. Para sa bawat site, pwede kang mag-set ng hiwalay na root folder, access log, error log, redirect rules, SSL certificate, cache policy, at security rule. Halimbawa, pwede mong ilagay ang corporate site sa /var/www/korporasyon/public, ang blog sa /var/www/blog/public, at testing environment naman sa /var/www/staging/public.

Efficient si Nginx sa ganitong setup dahil sa event-driven architecture nito—kaya niyang mag-handle ng maraming sabay-sabay na koneksyon na mababa ang resource consumption. Madalas itong gamitin sa shared hosting, VPS, cloud server, at high-traffic web apps. Para mag-work nang maayos ang multi-site hosting, dapat tama ang file permissions, DNS routing, SSL setup, at log separation.

Kailan Ginagamit ang Nginx Server Blocks?

Ginagamit ang Nginx server blocks kapag kailangan mong mag-manage ng higit sa isang web entity sa iisang server. Pwedeng dalawang maliit na corporate site, o maramihang client projects, subdomain, o microservice. Ang mahalaga, logical na hiwalay ang bawat proyekto.

• Kung gusto mong mag-host ng maraming domain sa iisang VPS.
• Kung gusto mong i-redirect ang www at non-www sa canonical na address.
• Kung may subdomain na dapat mag-point sa ibang folder o app.
• Kung kailangan ng hiwalay na SSL at security policy para sa bawat site.
• Kung gusto mong i-monitor ang client projects gamit ang hiwalay na log files.
• Kung may iba-ibang app gaya ng Laravel, WordPress, static HTML, o Node.js sa isang server.

Halimbawa, isang digital agency ay pwedeng mag-host ng 8 low-traffic corporate sites sa isang 4GB RAM VPS. Pero dapat kalkulahin ang bandwidth, disk usage, PHP process count, DB load, at backup frequency. Kung mataas ang traffic o kailangan ng resource isolation, mas mainam ang mas malakas na VPS, cloud server, o managed hosting. Pwede mong i-compare ang Web Hosting at Korporatibong Hosting para sa tamang pagpili.

Mga Kailangan Bago Mag-Setup

Ang tutorial na ito ay para sa Ubuntu o Debian-based Linux server. Pwedeng magkaiba ang commands depende sa distro, pero pareho ang logic. Sa production, siguraduhing may backup bago mag-configure—maling Nginx setup ay pwedeng magpahinto sa lahat ng site mo.

Mga Teknikal na Paghahanda

• Linux user account na may root o sudo privileges.
• Naka-install at tumatakbong Nginx service.
• At least isang domain na naka-configure papunta sa server IP.
• Naka-open ang ports 80 at 443 sa firewall.
• Maayos na directory structure para sa site files.
• Valid SSL certificate o Let’s Encrypt para sa libreng SSL.
• PHP-FPM para sa PHP-based applications.

Sa DNS, ang A record ay nagpo-point ng main domain sa IPv4, AAAA para sa IPv6. Para sa www o subdomain, CNAME o A record ang ginagamit. Maaaring abutin ng ilang minuto hanggang 24 oras ang DNS propagation. Para mas mabilis ang setup, unahin ang DNS records bago mag-configure ng Nginx server blocks.

Recommended Directory Structure

Isa sa mga madalas na pagkakamali sa multi-site hosting ay ang paghalo-halo ng lahat ng files sa iisang folder. Mukhang madali sa umpisa pero mahirap mag-maintain, mag-backup, o mag-debug. Ang mas mainam na approach ay mag-set up ng hiwalay na parent folder para sa bawat domain, at sa loob nito ay may public, logs, at backups.

Halimbawa: /var/www/site1.com/public, /var/www/site1.com/logs, /var/www/site2.com/public, /var/www/site2.com/logs. Ang Nginx root ay dapat tumutukoy sa public folder. Sa ganitong paraan, hindi directly ma-access sa web ang sensitive files tulad ng .env, backups, o app files.

Para mag-test, maglagay ng simpleng index.html sa bawat site folder na may pangalan ng site. Sa production, ang folder ownership ay karaniwang www-data user o isang deployment user. Ang file permissions ay kadalasang 755 para sa folders, 644 para sa files. Sa WordPress o apps na kailangan ng writing, dapat specific lang sa uploads folder ang write access.

Step-by-Step: Paglikha ng Nginx Server Block

Ipapakita ang proseso gamit ang site1.com bilang example. Parehong method ang pwede mong gamitin para sa iba pang sites. Mahalagang mag-unique ang server_name, root, at log file sa bawat site.

1. Gumawa ng Site Folder

Una, gumawa ng folder para sa web files. Halimbawa: sudo mkdir -p /var/www/site1.com/public. Maglagay ng test file tulad ng /var/www/site1.com/public/index.html na may text na "Ito ay test page ng site1.com" para mabilis ma-verify.

Para sa tamang ownership: sudo chown -R www-data:www-data /var/www/site1.com. Kung iba ang deployment user mo, i-adjust ang group permissions. Iwasan ang 777 permission sa production—pwede itong ma-abuso ng attackers sa upload directories.

2. Gumawa ng Server Block File

Ang best practice sa Nginx ay ilagay ang inactive configs sa /etc/nginx/sites-available, at mag-link ng active configs sa /etc/nginx/sites-enabled gamit symbolic link. Halimbawa: /etc/nginx/sites-available/site1.com.

Sample HTTP server block:

server {
    listen 80;
    server_name site1.com www.site1.com;
    root /var/www/site1.com/public;
    index index.html index.htm;
    access_log /var/log/nginx/site1.com.access.log;
    error_log /var/log/nginx/site1.com.error.log;
    location / {
        try_files $uri $uri/ =404;
    }
}

Sa config na ito, ang listen 80 ay para sa HTTP, server_name para sa domains, root para sa folder, index para sa default file. Ang try_files ay magbabalik ng 404 kung walang makitang file o folder. Para sa static sites, sapat na ito.

3. I-enable ang Site

Para ma-activate ang config, gumawa ng symbolic link: sudo ln -s /etc/nginx/sites-available/site1.com /etc/nginx/sites-enabled/site1.com. Mas okay ito kaysa mag-copy ng files, dahil ang link ay laging synchronized kapag may changes.

Kung ayaw mong ma-override ng default Nginx page ang site mo, pwede mong tanggalin ang default config sa /etc/nginx/sites-enabled/default. Pero siguraduhin munang gumagana ang sariling server block mo.

4. I-test ang Config at I-reload si Nginx

Tuwing may pagbabago, mag-test muna gamit sudo nginx -t. Kapag walang error, mag-reload ng service: sudo systemctl reload nginx. Mas gentle ang reload kaysa restart dahil hindi nito pinapatay ang active connections.

Kapag may error, kadalasan ilalabas ng Nginx ang filename at line number ng syntax problem. Karaniwang issues: kulang na semicolon, wrong curly brackets, invalid path, o conflicting server_name. Huwag mag-reload hangga’t hindi naayos ang error.

Pagdagdag ng Ikalawa at Ikatlong Site

Ang kagandahan ng multi-site hosting ay madali na ang proseso pagkatapos ng unang tamang setup. Para sa site2.com, gumawa ng /var/www/site2.com/public, mag-configure ng /etc/nginx/sites-available/site2.com, baguhin ang root at log values, mag-link, at mag-test.

Sample config para sa ikalawang site:

server {
    listen 80;
    server_name site2.com www.site2.com;
    root /var/www/site2.com/public;
    index index.html;
    access_log /var/log/nginx/site2.com.access.log;
    error_log /var/log/nginx/site2.com.error.log;
    location / {
        try_files $uri $uri/ =404;
    }
}

Ang hiwalay na log file sa bawat site ay mahalaga. Halimbawa, kapag tumataas ang 404 errors sa isa, mabilis mong matutukoy ang cause. Pati traffic analysis, bot attacks, broken links, at performance issues ay ma-monitor per site.

SSL at HTTPS Configuration

Sa 2026 SEO standards, hindi na optional ang HTTPS—ito ay sign ng trust at technical excellence. Chrome at Firefox ay tinatanggalan na ng padlock ang HTTP sites; kung may payments, user accounts, forms, o admin panel ang site mo, kailangan ng SSL. Sa multi-site setup, bawat domain ay dapat may sariling certificate. Para sa SSL, bisitahin ang mga sertipiko ng SSL.

Kung gumagamit ka ng Let’s Encrypt, pwede kang kumuha ng certificate per domain gamit Certbot. Halimbawa: certbot --nginx -d site1.com -d www.site1.com. Awtomatikong mag-a-update ng config si Certbot pero mas mainam na i-review ang changes. Minsan, nagkakaroon ng duplicate blocks o redirect errors.

Karaniwan, ang HTTP traffic sa port 80 ay nire-redirect papunta sa 443 (HTTPS). Ang tamang 301 redirect ay nag-sesend ng permanent signal sa search engines. Piliin mo kung www o non-www ang canonical mo, at i-redirect lahat ng variation papunta roon. Halimbawa, kung gusto mo ang https://site1.com, i-redirect ang lahat ng www traffic (HTTP at HTTPS) papunta sa non-www. Nakakatulong ito para maiwasan ang duplicate content penalty.

Nginx Server Blocks para sa PHP at WordPress Sites

Kung static HTML ang gamit, simple lang ang config. Pero sa WordPress, Laravel, o custom PHP apps, kailangan ng PHP-FPM integration. Dapat may index.php sa config at ang PHP requests ay ituturo sa tamang socket. Halimbawa, sa Ubuntu PHP 8.3: /run/php/php8.3-fpm.sock. Depende ito sa version na naka-install.

Sample PHP config:

server {
    listen 80;
    server_name wordpress-site.com www.wordpress-site.com;
    root /var/www/wordpress-site.com/public;
    index index.php index.html;
    location / {
        try_files $uri $uri/ /index.php?$args;
    }
    location ~ php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    }
}

Sa WordPress, mahalaga ang try_files $uri $uri/ /index.php?$args para gumana ang permalinks. Para sa security, i-consider ang blocking ng xmlrpc.php access, rate limiting sa wp-login.php, at pagban sa PHP execution sa uploads folder. Para sa multiple WordPress sites, dapat hiwalay ang database, user, at regular ang updates. Kung gusto mo ng mas madaling managed WordPress hosting, tingnan ang WordPress Hosting.

Nginx Server Blocks vs. Apache VirtualHost

Parehong kaya ng Nginx at Apache ang multi-site hosting, pero magkaiba ang architecture. Ang best choice ay depende sa app requirements, management style, at performance needs.

Kung malaki ang dependency mo sa .htaccess, mas madali ang Apache. Pero para sa high traffic, caching, reverse proxy, at modern deployment flows, mas malakas si Nginx. Pwede ring mag-combine ng Nginx as reverse proxy at Apache as backend sa ilang setups.

Best Practices sa Security

Ang multi-site hosting ay tipid sa gastos pero may dagdag na security responsibility. Para hindi maapektuhan ang ibang site kapag may problema ang isa, dapat may isolation at least privilege principle.

• Gumawa ng hiwalay na database at database user para sa bawat site.
• Ang web root ay dapat sa public folder lang.
• Huwag ilagay sa web-accessible ang backups, .env, .git, config, o SQL files.
• Regular i-renew ang SSL at pilitin ang HTTPS redirect.
• Gumamit ng firewall tulad ng UFW, buksan lang ang essential ports.
• Regular mag-update ng Nginx at OS.
• Huwag pag-isahin ang access_log at error_log sa lahat ng site.
• Lagyan ng IP restriction o extra authentication ang admin panels.
• Iwasan ang 777 file permissions.

Magdagdag din ng security headers tulad ng X-Frame-Options, X-Content-Type-Options, Referrer-Policy, at Content-Security-Policy kung applicable. Ingatan ang CSP dahil kapag mali, pwede nitong ma-block ang script at styles. Mas mainam mag-test muna bago i-deploy. Para sa karagdagang security tips, bisitahin ang Seguridad ng Web Site.

Performance at SEO Tips

Ang Nginx server blocks ay nakaka-apekto sa performance at SEO. Mali ang redirect chains, canonical setup, kulang ang gzip o brotli compression, malaki ang log files, at hindi optimal ang cache—mabagal ang site mo. Sa SEO, mahalaga ang fast, secure, at stable site.

Piliin ang canonical version ng domain—i-redirect agad ang HTTP sa HTTPS, www sa non-www, o vice versa. Iwasan ang redirect chain na: http://site.com → http://www.site.com → https://www.site.com → https://site.com. Dapat isang 301 redirect lang.

Gamitin ang cache-control headers para sa static files. Pwedeng mag-retain ang images, CSS, JS sa browser, pero dapat may versioning o query string para sa mabilis magbago. Gamitin ang gzip compression para sa HTML, CSS, JS, JSON at bawasan ang bandwidth. Sa high-traffic sites, pwede kang mag-set up ng microcache, FastCGI cache, o CDN. Para sa global access, basahin ang Ano ang CDN.

Log Management at Monitoring

Sa multi-site hosting, ang log management ay susi sa mabilis na troubleshooting. Separate log files para sa bawat site ay nagpapadali mag-track ng issues. Ang access_log ay para sa visitor requests, error_log ay para sa config, permissions, file missing, at upstream errors. Ang 502 Bad Gateway ay kadalasang PHP-FPM o backend service issue. Ang 403 Forbidden ay permission o index file issue. Ang 404 Not Found ay kadalasang wrong root path, rewrite, o DNS problem.

Para hindi lumaki nang sobra ang logs, mag-set up ng logrotate. Sa maliit na projects, daily o weekly rotation ay sapat. Sa high-traffic sites, mas mainam ang central log collection, metrics monitoring, at alert system. Kapag napuno ang disk, hindi makakapagsulat ng logs si Nginx, pati database, at hindi na ma-access ang sites. Mag-set ng disk usage threshold bilang preventive measure.

Madaling Solusyon sa Common Errors

May ilang errors na madalas mangyari habang nagse-setup ng Nginx server blocks. Ang pag-alam nito ay nakakatipid ng oras.

• Maling site ang lumalabas: Suriin ang server_name conflicts at default server block.
• 403 Forbidden: Check ang root folder, file permissions, at existence ng index file.
• 404 Not Found: Review ang root path at try_files rule.
• 502 Bad Gateway: Siguraduhing running ang PHP-FPM at tama ang socket path.
• SSL certificate ng maling site: Check ang 443 server_name at certificate files.
• Redirect loop: Simplify ang HTTP-HTTPS at www redirects.
• Nginx reload error: Sundan ang nginx -t output para sa syntax fix.

May checklist ang mga veteran sysadmin: Tama ba ang DNS? Aktibo ba ang Nginx config? May root folder ba? Maayos ba ang permissions? Pumasa ba ang nginx -t test? Ano ang sinasabi ng log? Sundin ang sequence na ito para mabilis ang troubleshooting.

Production Checklist

Bago i-live ang site, gamitin ang checklist na ito para sa bawat site. Lalo na sa client projects, ang pag-document ng mga ito ay sign ng professional delivery.

• Tama ang A o AAAA record ng domain papunta sa IP ng server.
• Pinili ang canonical www o non-www version.
• HTTP ay ni-reroute sa HTTPS gamit ang 301 redirect.
• Valid ang SSL certificate at may auto-renewal.
• May hiwalay na root at log file sa bawat site.
• Pumasa sa sudo nginx -t ang config.
• May backup plan at tested ang restore process.
• File permissions ay minimum privilege lang.
• Open lang ang required ports sa firewall.
• Minonitor ang error logs ng at least 15 minutes pagkatapos mag-live.

Simple man itong checklist, malaki ang tulong para maiwasan ang downtimes. Lalo na ang SSL renewals, DNS checks, at log monitoring—madalas dito nagmumula ang mga hidden issues.

Konklusyon

Ang Nginx server blocks ay basic na paraan para mag-host ng maraming site sa isang server nang maayos, secure, at mabilis. Sa tamang directory structure, config files, redirect rules, HTTPS, log separation, at regular testing, smooth ang multi-site management. Parehong applicable ang prinsipyo sa maliit na portfolio site hanggang sa maramihang client projects.

Bago mag-publish ng bagong project, planuhin muna ang domain, server resources, at SSL needs; pagkatapos, sundan ang checklist sa itaas para sa step-by-step Nginx setup. Kung gusto mo ng mas manageable na infrastructure, review ang Hosting packages, VPS server, at mga sertipiko ng SSL ng Hostragons para sa tamang simula.

Mga Madalas Itanong

Ilang sites ang pwedeng i-host sa Nginx server blocks?

Technically, pwede kang mag-host ng napakaraming sites sa isang Nginx server; ang limit ay CPU, RAM, disk space, bandwidth, DB load, at PHP-FPM capacity. Sa low-traffic static sites, kaya ng dose-dosenang sites, pero sa heavy WordPress o e-commerce, mas mainam na limitahan.

Kailangan bang hiwalay ang SSL certificate sa bawat site?

Oo, bawat domain o subdomain na i-publish via HTTPS ay dapat kasama sa certificate. Pwedeng individual certificates, SAN, o wildcard. Ang mahalaga ay tama ang certificate files sa 443 server block ng Nginx.

Pwedeng mag-host ng subdomain sa Nginx server block?

Oo. Para sa blog.site.com o panel.site.com, mag-add ng hiwalay na server_name at root folder o backend application. Sa DNS, kailangan ng A o CNAME record para sa subdomain.

Ano ang pagkakaiba ng sites-available at sites-enabled?

Ang sites-available ay storage ng lahat ng config files; sites-enabled ay active configs. Kadalasan, symbolic link ang ginagamit para i-activate mula sites-available papunta sa sites-enabled. Mas madaling mag-enable o disable ng site gamit ito.

Bakit maling site ang lumalabas?

Pinakakaraniwang dahilan: maling DNS IP, mali ang server_name, default Nginx block ang nakaka-catch ng request, o maling SSL block sa 443. I-check ang DNS records, nginx -t output, active sites-enabled links, at access_log ng site.