☰

在 GCE 上使用最簡單的 nginx centos 設定會導致「連線被拒絕」？

tag-icon • tag-icon nginx firewall reverse-proxy google-cloud-platform node.js
在 GCE 上使用最簡單的 nginx centos 設定會導致「連線被拒絕」？

更新

我遵循了與下面相同的步驟，除了提供的通用VPS（不是谷歌）之外，它按預期工作，包括未列出的步驟，例如使用Certbot 啟用HTTPS...所以我的假設是我的GCE 中有一些特殊的配置誤解/誤用/不這樣做會導致下述問題。關於 GCE 這個東西有什麼想法嗎？

設定

我有一個安裝了 Debian 的 Google Cloud Compute Engine 實例。預設情況下，在設定此 GCE 實例期間，我透過提供的 GCE 防火牆選項允許 HTTP 和 HTTPS 流量。我透過 SSH 進入 GCE 實例並執行以下操作：

GCE http/https 權限所授予的螢幕截圖GCE 允許流量的證據

1.)安裝了nginx和ufw

sudo apt install nginx ufw

2.) 啟用 UFW 的規則，允許 HTTP、HTTPS 和 SSH 連接

sudo ufw allow (http/https/ssh)
sudo systemctl enable ufw
sudo systemctl start ufw

3.) 啟用 nginx 保留預設配置

sudo systemctl enable nginx
sudo nginx -t ( returned "ok" results )
sudo systemctl start nginx

4.) 確保我的網域指向正確的 IP

測試

冰壺測試

當我訪問該網域時，我仍然收到“domain.com 拒絕連接”錯誤如果我執行

curl localhost

如果我輸入，我會得到預期的預設內容

網路統計檢查

netstat -a

我可以看到我正在正確的連接埠上收聽外界的聲音

tcp        0      0 0.0.0.0:http            0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:ssh             0.0.0.0:*               LISTEN

超濾水檢查

如果我檢查我的防火牆規則，我會看到以下內容

sudo ufw status
SSH                        ALLOW       Anywhere                  
224.0.0.251 mDNS           ALLOW       Anywhere                  
22                         ALLOW       Anywhere                  
80                         ALLOW       Anywhere                  
443                        ALLOW       Anywhere                  
3000                       ALLOW       Anywhere                  
SSH (v6)                   ALLOW       Anywhere (v6)             
ff02::fb mDNS              ALLOW       Anywhere (v6)             
22 (v6)                    ALLOW       Anywhere (v6)             
80 (v6)                    ALLOW       Anywhere (v6)             
443 (v6)                   ALLOW       Anywhere (v6)             
3000 (v6)                  ALLOW       Anywhere (v6)

我相信這表明我的端口已正確打開。

平檢查

我可以透過網域 ping 我的伺服器，它會正確地傳回預期的 IP。

Pinging FizzBuzz.app [cor.rec.t.IP] with 32 bytes of data:
Reply from cor.rec.t.IP: bytes=32 time=33ms TTL=57
Reply from cor.rec.t.IP: bytes=32 time=33ms TTL=57
Reply from cor.rec.t.IP: bytes=32 time=33ms TTL=57
Reply from cor.rec.t.IP: bytes=32 time=34ms TTL=57

Ping statistics for cor.rec.t.IP:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 33ms, Maximum = 34ms, Average = 33ms

記錄檢查

當我訪問 /var/log/nginx/error.log 時，它是空的（在訪問結果失敗的域之後）

當我訪問 /var/log/nginx/access.log 時，它有一個條目，用於檢查“curl localhost”是否工作（它確實如此）

據我所知，nginx 沒有顯示任何錯誤。

結論

截至目前，我已經用盡了所有可能的途徑來解決這個問題，除了直接花錢尋求谷歌支持......我試圖使用盡可能簡單的用例來最小化變量，但我仍然發現自己“拒絕當我的網站由Google 託管時，透過IP 或網域造訪我的網站時會出現「connect」錯誤，當我將其由其他2 個提供者託管時，它運作得很好。結論？我一頭霧水...

答案1

我可以在你的問題中看到 3 個要點：nodejs 應用程式作為後端、nginx 不監聽連接埠 443 以及反向代理配置。讓我們將其分解並孤立地查看每個點。

  1. nodejs 應用程式：嘗試從本機主機存取它並確認它正確應答

捲曲http://127.0.0.1/3000

  1. nginx 沒有監聽連接埠 443：您必須為此在 nginx 上設定一個伺服器區塊，而且，從 HTTP 重新導向到 HTTPS 也是一個很好的想法：
server {
    listen 80 default_server;
    server_name fizzbuzz.app www.fizzbuzz.app;
    return 301 https://fizzbuzz.app$request_uri;
}


server {
    listen 8443 ssl;
    server_name fizzbuzz.app www.fizzbuzz.app;

    index index.html index.htm;

    access_log /var/log/nginx/fizzbuzz-access.log;
    error_log /var/log/nginx/fizzbuzz-error.log error;

     location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
     }

    ssl_certificate     /etc/ssl/certs/fizzbuzz.app-fullchain.pem;
    ssl_certificate_key /etc/ssl/private/fizzbuzz.app.key;
}

為了頒發證書，我建議您使用 certbot 或 ACME 腳本。

即使用 acme.sh 您可以使用以下命令頒發證書：

/root/.acme.sh/acme.sh --issue --nginx -d fuzzbuzz.app -d www.fuzzbuzz.ap

/root/.acme.sh/acme.sh --install-cert -d fuzzbuzz.app -d www.fuzzbuzz.app \
--cert-file /etc/ssl/certs/fuzzbuzz.app.crt \
--key-file /etc/ssl/certs/fuzzbuzz.app.key \
--fullchain-file ${CERTS_DIR}/fuzzbuzz.app-fullchain.pem \
--log /var/log/acme_log \
--reloadcmd "systemctl restart nginx"

頒發憑證並安裝到位後，重新啟動 nginx e 進行測試

  1. 第三點是將 nginx 設定為反向代理，以便透過 HTTPS 公開您的應用程式。我認為上面的配置應該有效。如果沒有，我建議您閱讀 GoCD 中的這篇文檔，它準確地解釋了此類配置：

配置反向代理

答案2

我想到了！

.應用程式!一直都是 .app TLD！

我正打算購買一個隨機域名，以便向評論者提供名稱和IP，只是為了好玩而選擇了一個.app（為這次測試想出了一個愚蠢的名稱），然後我讀到了這樣的內容：“. APP 是一個安全的網域名稱」您現在可以購買 Foobarington.app，但它需要 SSL 憑證才能連接網站。了解有關安全命名空間以及如何取得 SSL 憑證的更多資訊。

所以！當我嘗試將我的 .app 網域指向伺服器時，它不會加載，因為當時我的伺服器沒有 SSL 憑證。我打算使用 CertBot 來取得證書，但它們最初需要 http 存取才能執行自動證書授予操作。

我需要弄清楚如何讓 Certbot（或等效解決方案）使用此 TLD 類型和主機為我運行，但絕對是我所擁有的 TLD 類型產生了此問題！

相關內容