Xuất bản website ServBay ra Internet công cộng (Reverse Proxy, Tunnel & Chuyển tiếp cổng)

Ngoài việc phát triển trên máy cá nhân, rất nhiều người dùng chọn triển khai ServBay trên một máy chủ luôn hoạt động (chẳng hạn Mac mini đặt ở datacenter, máy tính bàn cố định ở văn phòng hay máy chủ Windows), sử dụng như origin backend server, rồi xuất bản website ra Internet công cộng để cung cấp dịch vụ. Cách làm này hoàn toàn khả thi trong môi trường sản xuất—đã có rất nhiều người dùng vận hành ổn định theo phương án này.

Tuy nhiên, nếu chưa hiểu rõ hành vi mạng mặc định của ServBay, bạn sẽ dễ gặp phải các vấn đề liên quan đến giao thức, chứng chỉ, host header, hoặc cấu hình mạng, dẫn đến hiện tượng “truy cập nội bộ bình thường nhưng Internet lại lỗi”. Bài viết này dành cho mọi ai muốn sử dụng ServBay như máy chủ origin backend: sẽ giải thích chi tiết hành vi mặc định, sau đó cung cấp các phương án triển khai theo thứ tự: Tunnel nội bộ → Reverse Proxy (khuyến nghị) → Chuyển tiếp cổng, cuối cùng là checklist chung cho xử lý sự cố truy cập.

Áp dụng cho nền tảng

Bài viết áp dụng cho cả ServBay for macOS và ServBay for Windows. Hai nền tảng này sử dụng quy tắc giao thức, hành vi listen, đường dẫn chứng chỉ hoàn toàn giống nhau, chỉ khác thư mục cài đặt gốc (macOS là /Applications/ServBay, Windows thường là C:\ServBay; tùy vào vị trí bạn cài). Web server mặc định cũng khác nhau: macOS mặc định dùng Caddy, Windows mặc định Nginx—đều có thể chuyển đổi qua lại giữa Nginx/Apache/Caddy.

Trước tiên: Hiểu hành vi mạng mặc định của ServBay

Hầu hết các vấn đề truy cập Internet đều xuất phát từ hiểu lầm về các hành vi mặc định sau:

Giao thức mặc định của website là HTTP & HTTPS. Ở chế độ này, mọi truy cập HTTP (80) đều bị 301 redirect sang HTTPS (443) mà không điều kiện. Đây là mặc định hiện đại có chủ ý—bạn nên dùng HTTPS, đừng quay lại HTTP 80 truyền thống.
HTTPS chọn website & chứng chỉ dựa vào SNI. Trên cùng một ServBay, nhiều site sử dụng SNI trong thủ tục bắt tay TLS (tức domain) để matching. Khi reverse proxy truy xuất về backend bằng HTTPS, bắt buộc phải gửi đúng SNI, không thì sẽ nhận mặc định site/chứng chỉ mặc định.
Mặc định listen trên tất cả interface mạng (0.0.0.0), cổng mặc định HTTP 80 / HTTPS 443, tự nhiên cho phép truy cập từ bên ngoài, thường không cần sửa địa chỉ binding.
Chứng chỉ HTTPS cục bộ được cấp bởi ServBay CA. ServBay tích hợp một CA nội bộ (xuất hiện trên Keychain là ServBay User CA - ECC Root) để cấp chứng chỉ cho website. Trình duyệt ngoài Internet mặc định không tin tưởng CA này—nhưng chỉ cần cấu hình CA này trên reverse proxy (hoặc bỏ qua xác thực) là được, không cần đăng ký chứng chỉ Internet công khai riêng cho đường upstream.

Lỗi phổ biến: HTTP & HTTPS + chỉ forward 80

Nếu giữ mặc định HTTP & HTTPS mà chỉ forward cổng 80, không xử lý 443: Client truy cập http://domain → ServBay trả về 301 https://domain → Client thử kết nối 443 → không có ai trả lời → lỗi truy cập. Tệ hơn, browser/HSTS sẽ cache redirect 301 này, càng gây khó dò lỗi.

Cách giải quyết không phải là quay lại HTTP 80, mà là làm cho HTTPS đi được đầu-cuối (xem bên dưới với reverse proxy).

So sánh ba phương án xuất bản

Phương án	Mô tả	Thích hợp với
Tunnel nội bộ (frpc / cloudflared...)	ServBay tích hợp sẵn, chủ động xây tunnel ra ngoài, không cần IP công cộng, không cần mở port	Không có IP công cộng, mạng LAN/nội bộ, muốn xuất bản nhanh nhất
Reverse Proxy phía trước (khuyến nghị)	Nginx/HAProxy/Caddy/Traefik nhận lưu lượng công cộng, quản lý chứng chỉ, và proxy HTTPS tới ServBay	Có IP công cộng, muốn gom chung gateway/có nhiều backend/hệ thống quản lý chứng chỉ tập trung
Chuyển tiếp cổng (NAT)	Gateway chuyển tiếp port công cộng trực tiếp về ServBay	Chỉ có 1 backend, biết rõ mình cần gì và đang làm gì

Phương án 1: Tunnel nội bộ (dễ nhất, không cần IP công cộng)

Nếu bạn không có IP công cộng, hoặc không muốn cấu hình proxy/chứng chỉ rườm rà, tunnel nội bộ có sẵn trên ServBay là lựa chọn tiết kiệm công sức nhất. Chúng chủ động kết nối ra ngoài từ ServBay, bỏ qua mọi rào cản NAT, IPv6, chuyển tiếp cổng, xác thực chứng chỉ v.v:

Cloudflare Tunnel (cloudflared) — xuất bản website nội bộ ra Internet qua mạng lưới Cloudflare toàn cầu, cấp HTTPS công cộng đáng tin tự động, không cần mở port. Lý tưởng khi bạn muốn domain + CDN/WAF ổn định.
frp (frpc) — kết nối đến server frps của bạn, hoàn toàn tự kiểm soát.
ngrok / Pinggy — tạo URL công cộng tạm thời, phù hợp cho demo/nghiệm thu Webhook, thử nghiệm nhanh.

Với đa số người dùng, chỉ cần mở một tunnel cloudflared là đủ để “xuất bản site nội bộ ra ngoài”, không cần đi tiếp reverse proxy/chuyển tiếp cổng bên dưới.

Phương án 2: Reverse Proxy phía trước + Proxy HTTPS (Khuyến nghị)

Đây là phương án được đề xuất cho môi trường sản xuất: reverse proxy cung cấp HTTPS đáng tin ở phía trước, giữ nguyên chế độ HTTP & HTTPS của site, proxy tới ServBay cũng qua HTTPS, đảm bảo mã hóa đầu-cuối.

Vì sao khuyến nghị proxy HTTPS upstream thay vì quay lại HTTP 80

Phần lớn tài liệu cũ vẫn hướng dẫn backend chạy HTTP và reverse proxy proxy qua HTTP thuần. Chúng tôi không khuyến nghị phương án truyền thống đó, trừ khi bạn thực sự hiểu rủi ro và lý do:

Mã hóa đầu-cuối: Kể cả reverse proxy và ServBay cùng nội mạng, mọi lưu lượng đều mã hóa, tránh bị sniffing hoặc chỉnh sửa trên đường truyền nội bộ.
Tận dụng khả năng giao thức hiện đại: Giữ HTTPS cho phép Frontend bật HTTP/2 (h2), được tận hưởng multiplexing, header compression, reuse kết nối và các ưu điểm hiệu năng. Dùng HTTP 80 sẽ khiến bạn kẹt trong công nghệ cũ.
Tránh các rắc rối do degrade giao thức: Một khi downgrade về HTTP sẽ phải đối mặt với redirect 301 của HTTP & HTTPS, cache HSTS, sinh URL ứng dụng sai v.v.
Tin cậy ServBay CA rất đơn giản: Việc dùng CA nội bộ của ServBay chỉ cần reverse proxy “trust” CA đó, hoặc tắt xác thực link upstream, cấu hình một lần dùng mãi.

Phương án HTTP 80 vui lòng xem phương án 3; chỉ cho ai thực sự cần và hiểu rõ rủi ro.

Các điểm quan trọng khi cấu hình reverse proxy

Đúng cho cả bốn loại reverse proxy. Dưới đây là ví dụ nhất quán: domain public là example.com, backend ServBay là 192.168.1.115, backend HTTPS cổng 443, site ServBay giữ chế độ HTTP & HTTPS.

Proxy HTTPS lên backend: reverse proxy cấu hình proxy_pass/upstream đến https://192.168.1.115:443.
Gửi đúng SNI: trường SNI phải đúng domain trên ServBay (example.com), nếu không ServBay sẽ không trả về đúng site/chứng chỉ.
Reverse proxy tin cậy CA ServBay (Khuyến nghị) hoặc bỏ xác thực (dễ hơn): Xem phần sau để copy CA.
Giữ nguyên header Host: Host: example.com giúp ServBay xác định đúng site thông qua server_name.
Gửi X-Forwarded-Proto: https: Giúp app backend biết traffic gốc là HTTPS, tránh sinh URL http/thực hiện redirect vòng.
Đảm bảo IPv4/IPv6 đồng nhất: Xem Đồng nhất IPv4/IPv6.

Lấy ServBay CA (để reverse proxy tin cậy chứng chỉ SSL backend)

File chứng chỉ root CA nội bộ nằm trong thư mục cài ServBay:

macOS: /Applications/ServBay/ssl/private/ServBay-Private-CA-ECC-Root.crt
Windows: C:\ServBay\ssl\private\ServBay-Private-CA-ECC-Root.crt (tùy đường dẫn cài thực tế)

Chép file .crt này sang máy reverse proxy (thường /etc/nginx/servbay-ca/), cấu hình làm CA trust cho proxy upstream.

Về chuỗi chứng chỉ

ServBay sử dụng mô hình hai tầng “root CA + intermediate CA”, các site được CA trung gian cấp. Nếu reverse proxy chỉ trust root CA mà xác thực upstream vẫn fail, bạn nên ghép root cùng intermediate (ServBay-Private-CA-ECC-Intermediate.crt, cùng thư mục) thành 1 CA bundle để reverse proxy trust; hoặc có thể cấu hình “bỏ xác thực” để thử line trước, khi ổn thì chuyển về xác minh nghiêm ngặt.

Reverse Proxy Nginx (Proxy HTTPS upstream)

nginx

server {
    listen 443 ssl;
    listen [::]:443 ssl;                 # Hỗ trợ IPv6 nếu cần
    server_name example.com;

    # Chứng chỉ công cộng cho ngoài Internet (ví dụ Let's Encrypt)
    ssl_certificate     /etc/nginx/certs/example.com/fullchain.pem;
    ssl_certificate_key /etc/nginx/certs/example.com/privkey.pem;

    location / {
        proxy_pass https://192.168.1.115:443;                 # Proxy HTTPS về ServBay

        # — Quan trọng: SNI & xác thực CA —
        proxy_ssl_server_name on;                             # Kích hoạt gửi SNI
        proxy_ssl_name        example.com;                    # SNI = domain ServBay
        proxy_ssl_trusted_certificate /etc/nginx/servbay-ca/servbay-ca-bundle.crt;
        proxy_ssl_verify      on;                             # Trust ServBay CA rồi bật xác minh
        proxy_ssl_verify_depth 2;                             # root + intermediate (2 tầng)
        # Phương án nhanh (không config CA): proxy_ssl_verify off;

        # — Quan trọng: Giữ nguyên Host & protocol —
        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;
    }
}

# HTTP chuyển luôn sang HTTPS (reverse proxy xử lý thống nhất)
server {
    listen 80;
    listen [::]:80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

Reverse Proxy HAProxy (Proxy HTTPS upstream)

haproxy

frontend fe_web
    bind :80
    bind :443 ssl crt /etc/haproxy/certs/example.com.pem
    http-request redirect scheme https unless { ssl_fc }
    http-request set-header X-Forwarded-Proto https if { ssl_fc }
    default_backend be_servbay

backend be_servbay
    option forwardfor
    http-request set-header Host example.com
    # Proxy HTTPS: bật ssl + SNI + xác thực CA ServBay
    server servbay1 192.168.1.115:443 ssl sni str(example.com) \
        verify required ca-file /etc/haproxy/servbay-ca/servbay-ca-bundle.crt
    # Phương án nhanh: server servbay1 192.168.1.115:443 ssl sni str(example.com) verify none

Reverse Proxy Caddy (Proxy HTTPS upstream)

Caddy tự xin và gia hạn chứng chỉ công cộng cho example.com, reverse_proxy mặc định giữ nguyên Host và các header X-Forwarded-*:

caddy

example.com {
    reverse_proxy https://192.168.1.115:443 {
        header_up Host {host}
        transport http {
            tls_server_name example.com                                  # SNI
            tls_trusted_ca_certs /etc/caddy/servbay-ca/servbay-ca-bundle.crt
            # Phương án nhanh: tls_insecure_skip_verify
        }
    }
}

Reverse Proxy Traefik (Proxy HTTPS upstream)

Ví dụ cấu hình động với file provider:

yaml

# traefik-dynamic.yml
http:
  routers:
    servbay:
      rule: "Host(`example.com`)"
      entryPoints:
        - websecure
      service: servbay
      tls:
        certResolver: letsencrypt
  services:
    servbay:
      loadBalancer:
        passHostHeader: true                 # Giữ nguyên Host
        servers:
          - url: "https://192.168.1.115:443" # Proxy HTTPS upstream
        serversTransport: servbay-tls

serversTransports:
  servbay-tls:
    serverName: example.com                  # SNI
    rootCAs:
      - /etc/traefik/servbay-ca/servbay-ca-bundle.crt
    # Phương án nhanh: insecureSkipVerify: true

Phương án 3: Chuyển tiếp cổng (NAT)

Nếu chỉ có một backend, có thể trực tiếp cấu hình trên router/gateway chuyển tiếp port công cộng về máy ServBay (giả sử IP nội bộ là 192.168.1.115).

Khuyến nghị: Chuyển tiếp cả cổng 443, giữ HTTPS

Cấu hình NAT gateway: Public 443 → 192.168.1.115:443 (và Public 80 → 192.168.1.115:80 để ServBay redirect 80 sang 443).
DNS domain trỏ A record về IP công cộng.
Site giữ chế độ HTTP & HTTPS. Do visitor truy cập trực tiếp ServBay, phải cấp chứng chỉ công cộng hợp lệ cho domain này (xem thêm bên dưới); nếu không, trình duyệt sẽ cảnh báo lỗi chứng chỉ.
Đảm bảo đồng bộ IPv4/IPv6 (xem mục kế tiếp).

Chỉ chuyển tiếp HTTP 80 (cảnh báo đặc biệt)

Chỉ chuyển tiếp 80 và cấu hình site chế độ HTTP sẽ mất hoàn toàn mọi lợi ích của HTTPS & HTTP/2 và tiềm ẩn xung đột với browser HSTS/cache. Chỉ nên dùng nếu thực sự cần thiết và hiểu rõ hậu quả. Nếu bắt buộc, đặt site chế độ HTTP (tránh redirect 301 sang 443), chỉ forward port 80.

Đồng nhất IPv4/IPv6

Đây là nguyên nhân phổ biến dẫn đến truy cập bất ổn từ Internet. Nếu domain vừa có A (IPv4) và AAAA (IPv6) record, client sẽ chạy “Happy Eyeballs” và đôi khi ưu tiên IPv6; nếu bạn chỉ setup forward/proxy cho IPv4 mà không làm gì với IPv6, các truy cập bằng IPv6 sẽ lỗi. Cách xử lý:

Chỉ dùng IPv4: Đảm bảo dig AAAA domain +short không trả về gì, xóa hết AAAA chỉ giữ A record.
Hỗ trợ cả IPv6: Cấu hình forward/proxy cho IPv6, reverse proxy listen [::], backend cũng phải truy cập được qua IPv6.

Checklist xử lý sự cố truy cập

Nếu truy cập Internet gặp lỗi (không vào được, timeout, lỗi SSL, sai site...) hãy kiểm tra lần lượt (giả sử domain example.com, backend 192.168.1.115):

Có bị 301 redirect tới 443 chưa mở không?
bash
```
curl -I http://example.com
```
1
Thấy trả về 301 với Location: https://... mà chưa mở/forward 443 → lỗi này. Triển khai full HTTPS (khuyến nghị) hoặc chuyển site sang chế độ HTTP.

Có phải do IPv6?

bash

curl -4 -I https://example.com     # Chỉ test IPv4
curl -6 -I https://example.com     # Chỉ test IPv6
dig A example.com +short
dig AAAA example.com +short        # Có AAAA mà IPv6 không route được → xóa AAAA hoặc triển khai IPv6 cho đồng bộ

SNI / chứng chỉ proxy về backend có đúng không? (case proxy HTTPS upstream) Test kết nối SNI trực tiếp:
bash
```
curl -I --resolve example.com:443:192.168.1.115 https://example.com \
     --cacert /path/servbay-ca-bundle.crt
```
1
2
Nếu lỗi chứng chỉ/sai site, thường là do SNI hoặc CA chưa trust đúng.
Request có thực đi tới ServBay không? Kiểm tra log truy cập web server của site trên máy ServBay (“Xem Log File” trong ServBay). Nếu request timeout mà không có log → tắc ở network/gateway/reverse proxy.
Header Host có đúng không? (Trường hợp reverse proxy L7)
bash
```
curl -k -I -H "Host: example.com" https://192.168.1.115/
```
1
Kết nối trực tiếp vẫn được, qua reverse proxy thì lỗi → do proxy không truyền Host đúng.

Về chứng chỉ & bảo mật

Đường link proxy về backend ServBay: Khi reverse proxy truy cập về backend qua HTTPS, hãy cấu hình trust ServBay CA (ServBay-Private-CA-ECC-Root.crt, ghép intermediate nếu cần); đây là hệ thống tin cậy nội bộ, cấu hình duy nhất, dùng lâu dài.
Chứng chỉ công khai đối với visitor Internet: Dịch vụ client nên sử dụng chứng chỉ công khai hợp lệ. Với reverse proxy, certificate do proxy quản lý (Caddy/Traefik tự động xin/gia hạn). Với phương án chuyển tiếp port, phải cài public certificate trên chính ServBay (có thể tham khảo cách cấp SSL theo ACME). Chứng chỉ tự ký ServBay User CA chỉ dùng nội bộ/lab, Internet visitor không trust.
Không expose cơ sở dữ liệu ra Internet theo website: Khi mở website ra ngoài Internet, tuyệt đối không mở kèm port mysql, redis, memcached... Chú ý bảo mật này đã ghi rõ ở Truy cập nội bộ.
Firewall: Chỉ mở các port thực sự dùng, còn lại chặn hết.

Câu hỏi thường gặp (FAQ)

Hỏi: Truy cập nội bộ bình thường, từ Internet lại lỗi, phải do DNS không?
- Đáp: Đa phần không liên quan “không resolve được domain”, mà do redirect 301 từ chế độ HTTP & HTTPS đến 443 chưa mở, hoặc SNI/chứng chỉ chưa đúng, header Host chưa truyền, hoặc không đồng nhất IPv4/IPv6. Hãy kiểm tra tuần tự các bước checklist.
Hỏi: Bắt buộc phải dùng HTTP 80 mới proxy được về backend?
- Đáp: Không cần, cũng không nên. Giữ HTTP & HTTPS, reverse proxy proxy bằng HTTPS về ServBay và cấu hình trust ServBay CA (hoặc tắt xác thực); vậy vừa an toàn đầu-cuối vừa có HTTP/2.
Hỏi: Reverse proxy proxy về backend báo lỗi chứng chỉ/sai site?
- Đáp: Kiểm tra đã gửi đúng SNI (= domain), reverse proxy đã trust CA ServBay chưa (ghép intermediate nếu cần). Có thể cấu hình tắt xác thực để thử line, sau đó bật lên lại.
Hỏi: ServBay làm server sản xuất ổn định không?
- Đáp: Hoàn toàn ổn. Nhiều người đã triển khai trên Mac mini hoặc Windows server đặt ở IDC. Quan trọng là đồng nhất chế độ giao thức, SNI, Host header, xác thực chứng chỉ và IPv4/IPv6.
Hỏi: Không có IP công cộng thì làm sao xuất bản?
- Đáp: Dùng Phương án 1: Tunnel nội bộ (cloudflared/frpc), không cần IP public/content forwarding.

Kết luận

Xuất bản ServBay như origin backend lên Internet công cộng là hoàn toàn khả thi về mặt kỹ thuật. Lộ trình khuyến nghị: Duy trì chế độ HTTP & HTTPS cho website, dùng reverse proxy phía trước proxy bằng HTTPS và gửi đúng SNI, tin cậy ServBay CA để có mã hóa đầu-cuối và các tính năng hiện đại như HTTP/2; nếu không có IP công cộng, dùng tunnel cloudflared/frpc là nhanh nhất; chuyển tiếp cổng chỉ nên dành cho ai nắm rõ nhu cầu kỹ thuật. Khi gặp vấn đề truy cập, hãy kiểm tra mọi mục trong checklist của bài viết này—rắc rối gần như luôn xoay quanh: chế độ giao thức, SNI/chứng chỉ, header Host hoặc cấu hình IPv4/IPv6.

Xuất bản website ServBay ra Internet công cộng (Reverse Proxy, Tunnel & Chuyển tiếp cổng) ​

Trước tiên: Hiểu hành vi mạng mặc định của ServBay ​

So sánh ba phương án xuất bản ​

Phương án 1: Tunnel nội bộ (dễ nhất, không cần IP công cộng) ​

Phương án 2: Reverse Proxy phía trước + Proxy HTTPS (Khuyến nghị) ​

Vì sao khuyến nghị proxy HTTPS upstream thay vì quay lại HTTP 80 ​

Các điểm quan trọng khi cấu hình reverse proxy ​

Lấy ServBay CA (để reverse proxy tin cậy chứng chỉ SSL backend) ​

Reverse Proxy Nginx (Proxy HTTPS upstream) ​

Reverse Proxy HAProxy (Proxy HTTPS upstream) ​

Reverse Proxy Caddy (Proxy HTTPS upstream) ​

Reverse Proxy Traefik (Proxy HTTPS upstream) ​

Phương án 3: Chuyển tiếp cổng (NAT) ​

Đồng nhất IPv4/IPv6 ​

Checklist xử lý sự cố truy cập ​

Về chứng chỉ & bảo mật ​

Câu hỏi thường gặp (FAQ) ​

Kết luận ​