子文件夾 vs 子域名

哪種方法更好?為什麼? 我參與了一個有關使用子文件夾與子域名的討論。 假設我想在我的網站上創建一個新的部分,專門用於銷售蜂蜜。 我自己不生產也不銷售蜂蜜,這只是個例子。雖然我的一個朋友有蜜蜂並生產自己的蜂蜜,而且非常好吃 😋 蜂蜜部分的網站將會非常龐大,擁有自己的應用程序來管理電子商務。 我可以通過兩種方式將這個功能添加到我的網站上。第一種方式是使用子文件夾,如:flaviocopes.com/honey。 第二種方式是使用子域名,例如:honey.flaviocopes.com。 還有第三個選項,就是使用自己的域名,如:flaviohoney.com。但我們把注意力集中在保留原始域名上。 子域名更容易管理:你有自己完全獨立的應用程序、CMS或其他東西,如果你用CI/CD,你可以將其分開存儲在自己的Git存儲庫中,而且你還可以將其分開托管在自己的服務器上。 我認為這是理想的解決方案,當你使用像Shopify這樣的外部服務時,它們允許你使用子域名。 另一方面,子文件夾略微複雜,因為除非你在服務器端想出創意的方法(這意味著你需要管理自己的服務器),否則所有代碼都必須放在管理主域名的原始代碼下。 但有一個巨大的優勢將導致選擇子文件夾的方式:SEO。 Google並未正式確認這一點,但它將子域名視為與主域名完全不同的網站。 honey.flaviocopes.com不會繼承 flaviocopes.com 可能具有的 SEO “權重”。擁有許多子域名將導致域名權威分散為多個子域名,而不是集中在主域名中。 僅憑這個理由就足以證明選擇 flaviocopes.com/honey 。 從品牌的角度來看,我個人不認為有什麼不同。對於一個大型項目來說,擁有獨立的域名、標誌和設計會更好得多。但如果只是一個想法或者你想要進行試驗而不想花費時間和精力來擁有一個獨立的域名,那麼子文件夾和子域名的方法都可以。

用於從子文件夾中提供多個Node.js應用程序的簡單nginx反向代理

最近我在DigitalOcean上設置了一個VPS,以在同一域名下運行幾個不同的Node.js腳本。 現在,您無法使兩個不同的Node.js應用程序監聽同一個端口,因此必須使用反向代理。常用的方法是使用Nginx。 我將每個Node應用程序設置為在自己的子文件夾中運行,所以我需要編輯Nginx配置: sudo nano /etc/nginx/sites-available/default 配置文件原始內容如下: server { listen 80 default\_server; listen [::]:80 default\_server; root /var/www/html; index index.html index.htm index.nginx-debian.html; server\_name hellonode; location ^~ /assets/ { gzip\_static on; expires 12h; add\_header Cache-Control public; } location / { proxy\_http\_version 1.1; proxy\_cache\_bypass $http\_upgrade; proxy\_set\_header Upgrade $http\_upgrade; proxy\_set\_header Connection 'upgrade'; proxy\_set\_header Host $host; 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://localhost:3000; } } 這個配置允許一個Node.js應用程序在端口3000上運行,並且是主要在/處提供服務的應用程序。 我希望在/myservice下運行一個應用程序,所以我創建了一個在端口3001上監聽的Node應用程序,並添加了以下配置: location /myservice { rewrite ^/myservice/(....