Cách chạy Cloudflare Tunnel trên VPS không mở cổng

Cloudflare Tunnel hoạt động như thế nào và ý nghĩa thực sự của việc không mở cổng

Cloudflare Tunnel chạy một daemon nhỏ gọi là cloudflared trên VPS của bạn. Daemon này mở một kết nối hướng ra ngoài tới Cloudflare và duy trì kết nối đó. Các yêu cầu truy cập hostname của bạn sẽ đến edge của Cloudflare và được đẩy ngược lại qua kết nối đã thiết lập sẵn, vì vậy không có kết nối nào cần phải đi vào máy chủ của bạn.

Bước mà hầu hết các hướng dẫn đều bỏ qua: việc cài đặt tunnel không tự động đóng bất cứ thứ gì. Nếu cổng 80 và 443 vẫn mở trong firewall và ứng dụng của bạn vẫn đang lắng nghe trên 0.0.0.0, bạn chỉ đang thêm một lối vào thứ hai thay vì thay thế lối vào cũ. IP gốc của bạn vẫn có thể truy cập được và bất kỳ ai tìm thấy nó đều có thể đi thẳng vào mà không cần qua Cloudflare. Việc đóng các cổng đó là một bước thủ công, và đây chính là bước làm cho mọi cấu hình phía trên trở nên có giá trị.

cloudflared cần quyền truy cập hướng ra ngoài tới region1.v2.argotunnel.com và region2.v2.argotunnel.com trên cổng 7844. Nó sử dụng UDP cho giao thức QUIC và chuyển sang TCP cho HTTP/2 nếu cần. Trên mạng có áp dụng egress filtering, hãy cho phép cả hai, hoặc ép buộc sử dụng đường truyền TCP bằng --protocol http2.

Trước khi bắt đầu

• Một domain đã có trên tài khoản Cloudflare, với các nameserver của Cloudflare đang quản lý zone đó. cloudflared tunnel route dns ghi các bản ghi vào zone này, vì vậy zone phải tồn tại trước.
• Cho phép truy cập outbound trên cổng 7844 từ VPS, cả UDP và TCP.
• Một ứng dụng đã lắng nghe cục bộ, ngay cả khi đó chỉ là python3 -m http.server 8080 cho lần kiểm tra đầu tiên.
• sudo trên máy chủ, và một phiên SSH thứ hai đang mở trước khi bạn can thiệp vào firewall.

Cài đặt cloudflared trên Ubuntu hoặc Debian

Cloudflare đính kèm một gói .deb vào mỗi bản cloudflared, vì vậy việc cài đặt chỉ cần một lần tải xuống và một lệnh dpkg.

curl -fsSL -o /tmp/cloudflared.deb \
  https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
sudo dpkg -i /tmp/cloudflared.deb
cloudflared --version

Hãy chạy dpkg --print-architecture trước nếu bạn không chắc chắn về kiến trúc của máy chủ. Trên nền tảng ARM 64-bit, tên tệp kết thúc bằng arm64 thay vì amd64 và không có thay đổi nào khác. Việc in ra chuỗi phiên bản bằng cloudflared --version là xác nhận duy nhất bạn cần trước khi tiếp tục.

Một gói được cài đặt theo cách này nằm ngoài lộ trình cập nhật của apt, vì vậy apt-get upgrade sẽ không bao giờ tự động cập nhật nó và việc cập nhật trở thành trách nhiệm của bạn. sudo cloudflared update sẽ tải bản phát hành mới nhất và thay thế tệp binary tại chỗ; sau khi service đã tồn tại, hãy chạy tiếp sudo systemctl restart cloudflared để tiến trình đang chạy sử dụng tệp binary mới. Hãy đưa việc này vào lịch trình bảo trì định kỳ của bạn, vì tunnel daemon là phần mềm tiếp xúc với Internet mặc dù nó không mở bất kỳ cổng nào.

Đăng nhập và tạo tunnel có tên

cloudflared tunnel login

Trên VPS không có giao diện đồ họa, trình duyệt sẽ không tự mở. Hãy copy URL được in ra, dán vào trình duyệt trên laptop của bạn và chọn zone. Khi hoàn tất, ~/.cloudflared/cert.pem sẽ được tạo.

cert.pem là thông tin xác thực tài khoản của bạn. Nó cho phép tạo tunnel, ghi bản ghi DNS vào zone đó và xóa tunnel. Tunnel đang chạy không bao giờ sử dụng file này. Hãy bảo mật nó như mật khẩu, vì bất kỳ ai có bản sao của file này đều có thể tạo hostname mới trên domain của bạn.

cloudflared tunnel create homelab

Nếu chạy thành công, hệ thống sẽ in ra cả hai dòng dưới đây. UUID trong các dòng này là giá trị bạn cần dán vào file cấu hình.

Tunnel credentials written to /home/you/.cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json. cloudflared chose this file based on where your origin certificate was found. Keep this file secret. To revoke these credentials, delete the tunnel.
Created tunnel homelab with id 6ff42ae2-765d-4adf-8112-31c55c1551ef

File JSON đó là danh tính của tunnel và là thông tin xác thực duy nhất mà service đang chạy cần. Bất kỳ ai giữ file này đều có thể đăng ký làm tunnel của bạn và nhận lưu lượng truy cập. Không có cách nào để xoay vòng (rotate) riêng file này: việc thu hồi nó đồng nghĩa với việc cloudflared tunnel delete homelab và tạo một tunnel mới.

Lưu file thông tin xác thực ở vị trí an toàn

Dịch vụ chạy dưới quyền root, vì vậy hãy đặt file này trong một thư mục do root sở hữu thay vì để trong thư mục home, nơi mà các tác vụ backup hoặc tài khoản dùng chung có thể truy cập được.

sudo install -d -m 700 -o root -g root /etc/cloudflared
sudo install -m 600 -o root -g root \
  ~/.cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json \
  /etc/cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json
rm ~/.cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json
sudo ls -l /etc/cloudflared
cloudflared tunnel list

ls -l sẽ hiển thị -rw------- root root trên file JSON. cloudflared tunnel list đọc cert.pem, nên nó vẫn hoạt động bình thường và sẽ in ra tên tunnel, UUID cùng với số lượng kết nối hiện tại.

Viết file config.yml với các quy tắc ingress thực tế

Hãy viết cấu hình tại /etc/cloudflared/config.yml, không phải trong thư mục home của bạn. Lý do như sau. cloudflared service install sao chép bất kỳ cấu hình nào nó tìm thấy vào /etc/cloudflared/config.yml và sau đó hard-code --config /etc/cloudflared/config.yml vào unit của systemd. Nếu bạn tạo file trong ~/.cloudflared/config.yml, bản sao đó chỉ là một snapshot tại một thời điểm. Mọi chỉnh sửa sau đó đối với bản sao trong thư mục home đều không có tác dụng, service vẫn tiếp tục phục vụ các quy tắc cũ và không có cảnh báo nào cho bạn. Việc tạo file trực tiếp tại vị trí đích sẽ loại bỏ hoàn toàn vấn đề này.

tunnel: 6ff42ae2-765d-4adf-8112-31c55c1551ef
credentials-file: /etc/cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json
loglevel: info

ingress:
  - hostname: app.example.com
    service: http://127.0.0.1:8080
  - hostname: files.example.com
    service: http://127.0.0.1:8081
  - hostname: grafana.example.com
    path: ^/api/
    service: http://127.0.0.1:3000
  - service: http_status:404

Các quy tắc được đọc từ trên xuống dưới và quy tắc khớp đầu tiên sẽ được áp dụng. Một quy tắc không có hostname sẽ khớp với mọi hostname, đó là lý do tại sao quy tắc catch-all phải nằm cuối cùng. Nếu bỏ qua nó, cấu hình sẽ bị từ chối với The last ingress rule must match all URLs (i.e. it should not have a hostname or path filter). http_status:404 là một service tích hợp sẵn, nó trả về 404 và không làm gì khác. Nó rất cần thiết: nếu không có nó, một yêu cầu cho hostname mà bạn không định công khai sẽ rơi vào bất kỳ quy tắc thực tế nào nằm ở cuối danh sách.

Sử dụng 127.0.0.1 trong URL service: thay vì localhost. Trên Ubuntu, localhost phân giải thành ::1 trước, và một ứng dụng chỉ bind vào IPv4 loopback sẽ từ chối kết nối đó. Dòng log sẽ là dial tcp [::1]:8080: connect: connection refused và người truy cập sẽ thấy lỗi 502.

Sử dụng http:// thuần túy là chính xác ở đây vì kết nối không bao giờ rời khỏi máy chủ. Chỉ sử dụng https:// khi ứng dụng cục bộ yêu cầu TLS (transport layer security), và hãy chuẩn bị tinh thần gặp x509: certificate is valid for example.com, not localhost khi chứng chỉ của nó không khớp với tên bạn gọi. Hãy sửa lỗi đó bằng originServerName trong mục originRequest, hoặc chấp nhận rủi ro với noTLSVerify: true.

Kiểm tra các quy tắc trước khi khởi động bất cứ thứ gì:

sudo cloudflared --config /etc/cloudflared/config.yml tunnel ingress validate
sudo cloudflared --config /etc/cloudflared/config.yml tunnel ingress rule https://app.example.com/login

ingress validate sẽ báo cáo cấu hình hợp lệ hoặc chỉ ra quy tắc gây lỗi. ingress rule nhận một URL và in ra quy tắc đầu tiên khớp với nó, đây là cách nhanh nhất để biết rằng một regex path không khớp với những gì bạn giả định.

Trỏ DNS vào tunnel

cloudflared tunnel route dns homelab app.example.com
cloudflared tunnel route dns homelab files.example.com
cloudflared tunnel route dns homelab grafana.example.com

Mỗi lệnh gọi sẽ ghi một bản ghi CNAME được proxy trỏ tới 6ff42ae2-765d-4adf-8112-31c55c1551ef.cfargotunnel.com. Mục tiêu đó chỉ phân giải được bên trong mạng của Cloudflare, vì vậy kết quả DNS công khai cho hostname của bạn là một địa chỉ Cloudflare và IP VPS của bạn không bao giờ xuất hiện trong đó. Một wildcard hostname trong config.yml vẫn cần một bản ghi DNS khớp cho mỗi tên miền bạn thực sự sử dụng.

Khi một bản ghi đã tồn tại, lệnh sẽ thất bại như sau:

Failed to add route: code: 1003, reason: Failed to create record app.example.com with err An A, AAAA, or CNAME record with that host already exists.

Bản ghi hiện có đó gần như luôn là bản ghi A cũ trỏ tới IP công khai của VPS, đây chính xác là bản ghi bạn muốn loại bỏ. Hãy xóa nó trong bảng điều khiển Cloudflare, sau đó chạy lại lệnh. Nếu để nguyên, DNS sẽ tiếp tục công bố IP gốc của bạn, khiến tunnel không che giấu được gì cả.

Cài đặt nó như một service để tự khởi động sau khi reboot

Hãy chạy nó ở foreground một lần, vì lỗi sẽ dễ đọc trên terminal của bạn hơn là trong journal.

sudo cloudflared --config /etc/cloudflared/config.yml tunnel run homelab

Một lần khởi động thành công sẽ log ra vài dòng Registered tunnel connection, mỗi dòng cho một edge location, kèm theo connIndex tương ứng. Hãy tải một trong các hostname của bạn trên trình duyệt và xác nhận các ingress rule đưa bạn đến đúng nơi mong đợi, sau đó dừng nó bằng Ctrl-C.

sudo cloudflared --config /etc/cloudflared/config.yml service install
systemctl status cloudflared

Lệnh đó ghi /etc/systemd/system/cloudflared.service cùng với cloudflared-update.service và cloudflared-update.timer, sau đó chạy systemctl enable cloudflared.service và systemctl start cloudflared.service cho bạn. enable là phần quan trọng ở đây, vì nó là thứ giúp tunnel hoạt động trở lại sau khi reboot. ExecStart của unit là cloudflared --no-autoupdate --config /etc/cloudflared/config.yml tunnel run, đó là lý do tại sao đường dẫn cấu hình đó là bắt buộc.

Ba lỗi thường gặp ở bước này có thông báo cụ thể. possible conflicting configuration in /home/you/.cloudflared/config.yml and /etc/cloudflared/config.yml nghĩa là cả hai file đều tồn tại và cloudflared từ chối đoán: hãy xóa file bạn không cần. configuration file ... must contain entries for the tunnel to run and its associated credentials (tunnel: TUNNEL-UUID, credentials-file: CREDENTIALS-FILE) nghĩa là cấu hình của bạn đang dùng shorthand url: thay vì các key của named-tunnel, và shorthand đó không thể chạy như một service. cloudflared service is already installed nghĩa là một unit cũ vẫn còn tồn tại, vì vậy hãy chạy sudo cloudflared service uninstall trước.

Không có lệnh reload. Sau khi bạn chỉnh sửa /etc/cloudflared/config.yml, hãy chạy sudo systemctl restart cloudflared. Sau đó, hãy kiểm chứng việc tự khởi động thay vì chỉ giả định:

sudo reboot
# once it is back
systemctl is-enabled cloudflared
systemctl is-active cloudflared
journalctl -u cloudflared -n 50 --no-pager
curl -sI https://app.example.com

is-enabled in ra enabled và is-active in ra active chính là mục tiêu của phần này. Khi các route đã tồn tại và service đang chạy, cert.pem không còn việc gì phải làm trên server nữa: rm ~/.cloudflared/cert.pem. Việc thêm hostname sau này chỉ đơn giản là chạy lại cloudflared tunnel login.

Đóng cổng 80 và 443, nếu không tunnel chỉ là một đường dẫn thừa

Bạn cần thực hiện cả hai thay đổi. Nếu chỉ làm một, origin vẫn có thể bị truy cập từ bên ngoài.

Đầu tiên, bind ứng dụng vào địa chỉ loopback. Trong Nginx, điều này có nghĩa là dùng listen 127.0.0.1:8080; thay cho listen 80;, thao tác tương tự đã được hướng dẫn trong bài giải thích cấu hình Nginx reverse proxy này. Trong Docker Compose, điều này có nghĩa là dùng ports: - "127.0.0.1:8080:80". Cấu trúc "8080:80" thông thường sẽ publish trên mọi interface, và Docker tự ghi các quy tắc NAT (network address translation) mà gói tin sẽ đi qua trước khi ufw kịp kiểm soát, vì vậy quy tắc deny của ufw sẽ không chặn được. Bẫy này đã có bài viết riêng: tại sao các cổng đã publish của Docker lại bỏ qua ufw.

sudo ss -lntp

Mọi service bạn đã chuyển đổi giờ đây phải hiển thị 127.0.0.1:8080 trong cột Local Address. Một dòng hiển thị 0.0.0.0:8080 hoặc *:8080 nghĩa là nó vẫn đang lắng nghe từ Internet.

Thứ hai, đóng các cổng lại.

sudo ufw status numbered
sudo ufw delete allow 'Nginx Full'
sudo ufw status

Hãy xóa các quy tắc allow cho cổng 80 và 443 thay vì chồng các quy tắc deny lên trên, vì ufw dừng lại ở quy tắc khớp đầu tiên và quy tắc allow cũ nằm cao hơn trong danh sách sẽ được ưu tiên. Hãy giữ lại quy tắc SSH của bạn. Hướng dẫn cơ bản về tường lửa ufw bao gồm phần còn lại của bộ quy tắc đó. Hầu hết các nhà cung cấp VPS cũng chạy một tường lửa mạng riêng trong bảng điều khiển của họ, và đó không phải là ufw, vì vậy hãy đóng cổng 80 và 443 ở đó nữa.

Bây giờ hãy xác minh từ một nơi khác, vì lệnh curl http://127.0.0.1:8080 chạy ngay trên máy chủ không chứng minh được gì về khả năng truy cập từ bên ngoài.

# run these from a different machine
nc -vz 203.0.113.10 443
curl -sI https://app.example.com

Kết quả bạn cần là một thông báo từ chối hoặc timeout khi chạy nc vào IP gốc, kèm theo kết nối 200 thành công thông qua hostname. Kiểm tra xem một cổng có thực sự mở hay không bao gồm nhiều cách hơn để kiểm thử.

Tunnel chỉ là phương tiện truyền tải, không phải xác thực. Bất cứ thứ gì bạn publish qua tunnel đều có thể truy cập công khai trừ khi bạn đặt một lớp đăng nhập phía trước, có thể là Cloudflare Access tại edge hoặc một OAuth2 proxy đặt trước ứng dụng trên máy chủ. SSH cũng cần một giải pháp riêng vì tunnel không bao phủ nó: hãy giữ cổng 22 mở nhưng giới hạn chỉ cho phép các địa chỉ nguồn của riêng bạn.

Lợi ích và chi phí khi sử dụng Cloudflare Tunnel

Những gì bạn nhận được là thực tế. IP gốc của bạn không còn bị công khai, không có cổng inbound nào bị mở, thiết lập này hoạt động ngay cả trên máy không có IP public, chứng chỉ public là vấn đề của Cloudflare nên không cần chạy client ACME (automatic certificate management environment) trên máy của bạn, và các cuộc tấn công lưu lượng lớn được chặn tại edge thay vì tiêu tốn băng thông của bạn.

Chi phí cũng thực tế không kém. Cloudflare thực hiện TLS termination tại edge của họ: yêu cầu của người dùng được giải mã tại đó và mã hóa lại vào tunnel, vì vậy Cloudflare có thể đọc được lưu lượng. Đó là điều giúp các tính năng firewall, caching và Access rules của họ hoạt động, và không có cài đặt nào tắt được điều này khi bạn vẫn sử dụng proxy của họ. Nếu việc bên thứ ba nắm giữ dữ liệu plaintext của bạn là điều không thể chấp nhận, hãy dừng lại tại đây và chọn giải pháp khác.

Cloudflare cũng trở thành một dependency cứng đối với khả năng truy cập. Khi cloudflared không kết nối, người dùng sẽ nhận được trang Error 1033 của Cloudflare thay vì ứng dụng của bạn, và bạn đã chủ động loại bỏ đường dẫn trực tiếp mà họ có thể dùng làm phương án dự phòng.

Chỉ có HTTP, HTTPS và WebSocket mới có thể truy cập tới một hostname public từ trình duyệt thông thường. Bất kỳ giao thức TCP nào khác, SSH hoặc RDP (remote desktop protocol) hoặc game server, đều cần phần mềm ở phía client: cloudflared access tcp chuyển tiếp một cổng cục bộ, hoặc sử dụng WARP client. Không có cách nào khác không cần cài đặt client cho các giao thức đó.

Phần thân của request (request body) bị giới hạn tại edge, và một file upload vượt quá giới hạn sẽ bị từ chối với lỗi HTTP 413 trước khi nó kịp đến ứng dụng của bạn. Tính đến tháng 8 năm 2026, giới hạn này là 100 MB trên các gói Free và Pro, và cao hơn ở các gói trả phí, vì vậy hãy kiểm tra trang giới hạn hiện tại của Cloudflare trước khi thiết kế hệ thống dựa trên một con số cụ thể. Các điều khoản dịch vụ của Cloudflare cũng hạn chế việc sử dụng proxy chủ yếu để phục vụ video và các file lớn không phải HTML, điều này đáng để đọc trước khi bạn trỏ một thư viện media vào một tunnel miễn phí.

Cloudflare Tunnel, reverse SSH tunnel, hoặc Tailscale Funnel

Cả ba giải pháp này đều chỉ hoạt động theo chiều outbound, vì vậy chúng đều chạy được trên máy chủ không mở cổng inbound và không có IP public. Sự khác biệt nằm ở việc ai nắm giữ plaintext của bạn và hostname công khai mà người dùng nhìn thấy.

Reverse SSH tunnel cần một máy thứ hai có IP public, máy này sẽ đóng vai trò là cửa ngõ: chứng chỉ, reverse proxy và firewall trên đó đều do bạn quản lý. Không ai khác có thể giải mã dữ liệu của bạn. Cách này có nhiều thành phần cần cấu hình hơn và cần dùng autossh hoặc một systemd unit với Restart=always để duy trì kết nối sau khi mạng chập chờn. Hướng dẫn thiết lập reverse SSH tunnel cho CGNAT sẽ đi sâu vào quy trình này.

Tailscale Funnel là giải pháp tương đương nhất. Nó cũng chỉ hoạt động theo chiều outbound, và TLS termination diễn ra ngay trên máy của bạn, nên các relay của Tailscale không bao giờ thấy được plaintext. Đánh đổi ở đây là về tên miền và cổng: Funnel chỉ phục vụ các tên miền thuộc domain ts.net của tailnet, và chỉ trên các cổng 443, 8443 và 10000. Sự khác biệt giữa Tailscale Serve và Funnel giải thích rõ cả hai khía cạnh này.

Hãy chọn dựa trên ràng buộc thực tế của bạn. Chọn Cloudflare Tunnel khi người dùng cần truy cập qua domain riêng của bạn và bạn chấp nhận việc Cloudflare có thể đọc lưu lượng. Chọn Tailscale Funnel khi hostname dạng ts.net là chấp nhận được và bạn không muốn giao plaintext cho proxy. Chọn reverse SSH tunnel khi bạn đã có sẵn một máy chủ public và muốn loại bỏ hoàn toàn bên thứ ba khỏi đường truyền.

FAQ

Tôi có cần mở cổng 443 khi dùng Cloudflare Tunnel không?

Không. cloudflared kết nối hướng ra ngoài tới Cloudflare qua cổng 7844 và mọi yêu cầu đều quay ngược lại qua kết nối đó, vì vậy không có cổng inbound nào được sử dụng. Tuy nhiên, việc cài đặt tunnel không tự động đóng các cổng cho bạn. Hãy xóa các quy tắc cho phép cổng 80 và 443 trong ufw, đóng chúng trong firewall mạng của nhà cung cấp, bind ứng dụng vào 127.0.0.1, và xóa mọi bản ghi A còn sót lại đang công khai IP VPS của bạn. Xác nhận lại bằng sudo ss -lntp trên máy chủ và nc -vz <your-ip> 443 từ một máy khác.

Tại sao hostname của tôi hiển thị Cloudflare Error 1033?

Lỗi 1033 nghĩa là Cloudflare giữ bản ghi DNS cho hostname đó nhưng không tìm thấy cloudflared nào đang kết nối để nhận yêu cầu. Hoặc tiến trình đã dừng, hoặc nó đang chạy nhưng không thể kết nối tới Cloudflare. Kiểm tra systemctl status cloudflared và journalctl -u cloudflared -n 50, sau đó xác nhận cổng outbound 7844 đã được cho phép cho cả UDP và TCP, vì firewall chặn UDP và QUIC mà không cho phép fallback sang TCP sẽ gây ra lỗi này. cloudflared tunnel info homelab hiển thị các kết nối mà Cloudflare hiện đang thấy, nếu danh sách trống thì lỗi nằm ở phía bạn.

Tại sao tôi nhận lỗi 502 Bad Gateway qua tunnel?

Lỗi 502 nghĩa là cloudflared đã nhận được yêu cầu nhưng không thể kết nối tới dịch vụ local của bạn, vì vậy lỗi nằm giữa hai điểm đó chứ không phải tại Cloudflare. Hãy đọc log. dial tcp [::1]:8080: connect: connection refused nghĩa là không có gì đang lắng nghe tại địa chỉ bạn đã cấu hình, và [::1] trong thông báo đó thường do bạn viết localhost trong URL service: trong khi ứng dụng chỉ bind IPv4, hãy đổi thành http://127.0.0.1:8080. HTTP/1.x transport connection broken: malformed HTTP response là lỗi ngược lại: bạn viết https:// tại một origin chỉ hỗ trợ HTTP thuần.

Tôi có thể chạy SSH, RDP hoặc game server qua Cloudflare Tunnel không?

Không thể nếu chỉ dùng client thông thường. Một hostname công khai qua tunnel chỉ truyền tải HTTP, HTTPS và WebSocket, vốn là giao thức của trình duyệt. Mọi giao thức TCP khác đều cần phần mềm trên máy client, hoặc là cloudflared access tcp để forward cổng local, hoặc là client WARP. Nếu bạn muốn SSH từ bất kỳ máy nào mà không cần cài đặt gì thêm, tunnel không phải là công cụ phù hợp. Hãy giữ cổng 22 mở và giới hạn theo địa chỉ nguồn.

Cloudflare có thấy lưu lượng truy cập của tôi qua tunnel không?

Có. Cloudflare thực hiện TLS termination tại edge, giải mã yêu cầu tại đó, và mã hóa lại vào tunnel để gửi tới máy chủ của bạn. Việc giải mã này giúp các tính năng firewall, cache và chính sách Access hoạt động, đồng thời cũng có nghĩa là dữ liệu plaintext của bạn tồn tại trên máy chủ của họ. Không có cấu hình nào tránh được điều này khi bạn sử dụng proxy của họ. Nếu điều đó không chấp nhận được, hãy sử dụng Tailscale Funnel hoặc tự chạy reverse proxy trên một máy chủ công khai.