Tailscale serve vs funnel: ano ang dapat gamitin?
Alamin ang pagkakaiba ng Tailscale serve at funnel. Gamitin ang serve para sa private tailnet access at funnel para sa public internet. Basahin ang policy gate na nagba-block.
tailscale serve vs funnel: sino ang makaka-access sa URL
Ang pagkakaiba ng tailscale serve at tailscale funnel ay ang audience lamang, wala nang iba. Ang serve ay naglalagay ng HTTPS (hypertext transfer protocol secure) front end sa isang local port at ipinapa-publish ito sa iyong tailnet lamang. Ang funnel naman ay naglalagay ng parehong local port sa buong public internet, sa pamamagitan ng mga relay server na pinapatakbo ng Tailscale. Ang dalawang command ay gumagamit ng parehong mga flag at target. Isang salita lang ang naghihiwalay sa isang private dashboard at sa isang accessible sa buong mundo.
Pareho silang nagbibigay sa iyo ng certificate na pinagkakatiwalaan na ng mga browser, gamit ang pangalang nagtatapos sa ts.net, at hindi kailangan ng kahit anong inbound port na nakabukas sa iyong VPS firewall. Ang iyong tailscaled daemon ay mayroon nang koneksyon palabas sa tailnet, kaya doon dumadaan ang traffic. Ang paglalagay ng server sa tailnet ay isang trabaho, at ang pagpapatakbo ng VPS bilang Tailscale exit node o pag-advertise ng subnet router para sa isang private network ang sumasaklaw doon. Ang pag-publish naman ng serbisyong nasa tailnet na ay ang trabahong ito.
Mga kailangan bago gumana ang alinman sa command
- Tailscale 1.38.3 o mas bago sa VPS, na naka-log in sa iyong tailnet. I-check ito gamit ang
tailscale versionattailscale status. - Naka-enable ang MagicDNS. Ang MagicDNS ay ang built-in na DNS (domain name system) ng Tailscale, at ito ang nagbibigay sa machine ng pangalan gaya ng
blog-vps.your-tailnet.ts.netsa halip na100.xaddress lang. - Naka-enable ang HTTPS certificates para sa tailnet, sa pahina ng DNS sa admin console. Kung wala ito, walang certificate na mailalagay sa harap ng iyong port.
- Para sa
funnellamang, angfunnelnode attribute sa tailnet policy file. Dito madalas humihinto ang mga unang subok, at tatalakayin ito sa ibaba.
Ang bawat command dito ay nagsisimula sa sudo, dahil ang CLI ay nakikipag-usap sa tailscaled sa pamamagitan ng isang socket na root lang ang may pahintulot na sulatan. Magbigay ng karapatan sa isang user para hindi na ito kailanganin:
sudo tailscale set --operator=$USERI-publish sa iyong tailnet gamit ang tailscale serve
Ituro ang serve sa isang local port at ito na ang bahala sa iba.
sudo tailscale serve 3000Available within your tailnet:
https://amelie-workstation.pango-lin.ts.net
|-- / proxy http://127.0.0.1:3000
Press Ctrl+C to exit.Ang simpleng 3000 ay shorthand para sa http://127.0.0.1:3000. Ang Tailscale ay nakikinig sa port 443 ng tailnet address ng machine, tinatapos ang TLS (transport layer security) gamit ang ts.net certificate, at ipinapasa ang plain HTTP sa iyong local port. Hindi kailangang malaman ng iyong application na may certificate, na siyang pangunahing dahilan kung bakit ito ginagamit sa harap ng isang admin panel na kung hindi ay iiwan mo sa plain HTTP. Ang isang web UI na naka-bind lamang sa 127.0.0.1 ang malinaw na kandidato, at ang dsh Web UI sa port 3080 ay isang magandang halimbawa: sa halip na magbukas ng SSH tunnel sa tuwing kailangan mo ito, ituro ang serve sa 3080 nang isang beses at ma-access ito mula sa kahit anong device sa tailnet.
Ngayon, basahin ang huling linya: Press Ctrl+C to exit. Ang command ay tumatakbo sa foreground, at ang mapping ay nananatili sa loob ng prosesong iyon. Isara ang terminal at titigil ang paggana ng URL, dahil walang naisulat sa disk. Idagdag ang --bg at ang mapping ay mapupunta sa serve config ng node, na mananatili kahit isara ang terminal o mag-reboot.
sudo tailscale serve --bg 3000Ang serve ay tumatanggap ng higit pa sa port number. Ang --set-path ay nag-ma-mount ng serbisyo sa ilalim ng isang subpath, kaya maraming apps ang maaaring mag-share ng iisang hostname:
sudo tailscale serve --bg --set-path=/grafana 3000
sudo tailscale serve --bg --set-path=/metrics 9090Ang target ay maaari ring maging isang directory ng mga static file, o isang backend na gumagamit na ng TLS na may certificate na ayaw mong i-check:
sudo tailscale serve --bg /srv/reports
sudo tailscale serve --bg https+insecure://localhost:8443Hindi lang ito limitado sa HTTP. Ang --tcp=<port> ay nagpapasa ng raw TCP (transmission control protocol) stream, at ang --tls-terminated-tcp=<port> ay tinatapos ang TLS sa iyong node at ipinapasa ang plaintext, na naglalagay ng trusted certificate sa harap ng isang serbisyo na hindi gumagamit ng HTTP:
sudo tailscale serve --bg --tls-terminated-tcp=443 tcp://127.0.0.1:9899Bakit sinasabi ng funnel na hindi naka-set ang node attribute?
Naka-off ang funnel para sa buong tailnet bilang default. Ang unang pag-run nito ay maglalabas ng ganitong mensahe at hihinto:
Funnel not available; "funnel" node attribute not set. See https://tailscale.com/kb/1223/tailscale-funnel/.Tama ang command. Hindi binigyan ng tailnet policy ang node na ito ng pahintulot na mag-publish, kaya tumatanggi ang client bago pa man ito makipag-ugnayan sa relay. I-edit ang tailnet policy file sa admin console, sa ilalim ng Access Controls, at idagdag ang attribute:
"nodeAttrs": [
{
"target": ["autogroup:member"],
"attr": ["funnel"],
},
],Ang autogroup:member ay nagbibigay ng pahintulot sa bawat miyembro ng tailnet. Kung isang machine lang ang dapat mag-publish, lagyan ng tag ang machine na iyon at i-target ang tag, halimbawa ay tag:public. I-save ang policy, pagkatapos ay i-run muli ang funnel command.
Kung ikaw ay isang tailnet admin, nag-aalok ang mga bagong client ng shortcut: ang CLI ay maglalabas ng consent URL sa login.tailscale.com, at ang pag-follow dito ay mag-e-enable ng HTTPS certificates at magdadagdag ng attribute para sa iyo. Kung hindi ka admin, hindi makakatulong ang URL na iyon. Kailangang ang isang taong may access sa policy ang gumawa ng pagbabago.
I-publish sa internet gamit ang Tailscale Funnel
Kapag naka-set na ang attribute, ang command ay ang alam mo na rin, pero may ibang verb.
sudo tailscale funnel --bg 3000Available on the internet:
https://amelie-workstation.pango-lin.ts.net
|-- / proxy http://127.0.0.1:3000
Press Ctrl+C to exit.Basahin ang unang linya sa bawat pagkakataon. Ang Available within your tailnet at Available on the internet lamang ang nakikitang pagkakaiba sa pagitan ng private service at public service, at ang mga command na gumagawa sa mga ito ay nagkakaiba lang ng isang salita.
Simula noong Agosto 2026, ang funnel ay nakikinig lamang sa port 443, 8443, o 10000, at wala nang iba. Ang default ay 443, at ang --https=8443 o --https=10000 ang mga alternatibo. Tinatanggihan ang anumang ibang port dahil ang mga funnel relay ay tumatanggap lamang ng koneksyon sa mga port na ito. Iyan ang dahilan kung bakit ang funnel URL ay laging ang hostname lang, o ang hostname na may nakadikit na :8443 sa dulo.
Paano ko makikita ang kasalukuyang naka-publish?
Ang paghula ang dahilan kung bakit nananatiling public ang isang dashboard sa loob ng isang buwan. Tanungin na lang ang node.
tailscale serve status
tailscale funnel status
tailscale serve status --jsonParehong binabasa ng mga status command ang iisang config, kaya alinman sa dalawa ay magpapakita ng buong sitwasyon. Gamitin ang --json form sa loob ng isang script o scheduled check, dahil ang plain output ay nakasulat para sa tao. Kapag walang naka-configure, makakakuha ka ng isang linya:
No serve configKapag nakita mo iyan matapos ang isang setup na alam mong gumana, ibig sabihin ay ginawa ang mapping sa foreground at wala na ang proseso. Gawin itong muli gamit ang --bg.
Para mag-alis ng isang mapping, ulitin ang command na lumikha nito at ilagay ang off sa dulo. Para burahin ang lahat ng serve at funnel mapping sa node, gamitin ang reset.
sudo tailscale funnel --https=443 3000 off
sudo tailscale serve resetPatakbuhin muli ang tailscale serve status pagkatapos ng alinman sa dalawa at basahin kung ano ang natira, sa halip na ipagpalagay na nagawa nito ang gusto mong mangyari.
Ang makukuha mo, at ang isusuko mo
Totoo ang mga pakinabang, at ito ang dahilan kung bakit pinipili ito ng mga tao kaysa sa reverse proxy.
- Isang certificate na pinagkakatiwalaan ng mga browser, na kusa mong nare-renew. Walang ACME (automatic certificate management environment) client na kailangang i-install, at walang renewal job na makakalimutan.
- Walang inbound port sa VPS firewall. Ang
tailscaleday nagda-dial out, kaya ang default-deny ufw firewall sa iyong VPS ay mananatiling mahigpit gaya ng dati. - Walang DNS record na kailangang bilhin, ituro, o hintayin.
- Walang port forwarding, na siyang pangunahing solusyon para sa isang machine na nasa likod ng NAT (network address translation) sa halip na isang VPS na may public IP.
Totoo rin ang mga kapalit, at ang funnel ang may dala ng lahat ng ito.
- Hindi sa iyo ang pangalan. Ang mga public visitor ay makakakita ng
host.your-tailnet.ts.net. Ang Funnel ay walang suporta para sa custom domain, kaya hindi mo maaaring ilagay angapp.example.comsa harap nito. - Hindi sa iyo ang path. Ang traffic ay unang dadaan sa isang Tailscale relay, at ang relay ang magpo-proxy ng stream patungo sa iyong node sa loob ng tailnet. Ayon sa Tailscale, ang funnel traffic ay may mga bandwidth limit na hindi naka-publish at hindi maaaring i-configure, kaya sukatin ang sarili mong throughput bago ka umasa sa isang numero.
- Kulang ang mga control. Ang reverse proxy na ikaw ang nagpapatakbo ay nagbibigay sa iyo ng access logs, rate limits, request size caps, at lugar para maglagay ng authentication. Ang Funnel ay nagbibigay lang sa iyo ng URL. Lahat ng iba pa ay dapat nasa loob ng iyong application.
- Ang listahan ng port ay fixed, gaya ng nabanggit sa itaas.
Ang parehong feature ay nakadepende rin sa infrastructure na pinapatakbo ng Tailscale: ang pag-isyu ng certificate para sa pangalang ts.net, at ang mga funnel relay mismo. Kung dapat ka bang mabahala sa dependency na ito ay nakadepende sa kung ano ang kaya at hindi kayang gawin ng mga server na iyon sa iyong traffic, na siyang mismong ipinapaliwanag ng trust model ng Tailscale. Wala ring bayad ang paggamit sa alinman sa mga ito, dahil ang free plan ay sumasaklaw sa hanggang anim na user na may unlimited na device bawat isa, at ang bilang ng seat ang nagtutulak sa isang tailnet patungo sa paid plan, hindi ang listahan ng feature. Paglampas sa puntong iyon, ang bayarin ay nakabase sa mga user sa halip na sa mga machine, kaya sulit na tingnan ang kung magkano talaga ang halaga ng isang tailnet sa paid plan bago maging load-bearing ang serve o funnel. Kung pinag-iisipan mo ang isang self-hosted Headscale control server, huwag mong ipagpalagay na kasama ang alinman sa mga ito. Suriin ang release notes para sa bersyon ng Headscale na balak mong patakbuhin.
Alin ang dapat kong gamitin?
Maikli lang ang panuntunan.
Gamitin ang serve para sa anumang internal: mga admin interface, dashboard, metrics UI na ayaw mong ma-index, o staging copy ng isang site. Ang pagiging miyembro sa tailnet ang nagsisilbing access control, at epektibo ito. Ang device na wala sa tailnet ay hindi man lang makaka-resolve ng pangalan.
Gamitin ang funnel para sa demo link, webhook receiver na kailangang padalhan ng POST ng third party, o OAuth callback habang nagde-develop. Ito ang pinakamabilis na paraan para makakuha ng public HTTPS URL, at isang off command lang ang kailangan para tapusin ito. Pero tandaan, ang public ay public: hindi sikreto ang hostname, at ang funnel sa harap ng app na walang login ay isang open service. Anuman ang nasa likod nito ay dapat mag-authenticate ng sarili nitong mga request, nang may parehong pag-iingat na kailangan ng isang exposed na Ollama API endpoint.
Gumamit ng totoong reverse proxy para sa anumang ituturing mong production. Gamitin ang sarili mong domain, sariling certificate, sariling logs, sariling rate limit, at siguraduhing walang ibang nasa request path. Ang paghahambing sa nginx, Caddy, at Traefik bilang reverse proxy ay tumatalakay sa pagpili ng isa.
Mga mode ng pagkabigo, kasama ang mga string na makikita mo
Tumangging magsimula ang Funnel. Ang Funnel not available; "funnel" node attribute not set. ay isang problema sa policy, hindi sa command. Idagdag ang attribute na funnel sa tailnet policy file, i-save ito, at subukan muli.
Gumana ito, at ngayon ay sinasabi ng tailscale serve status na No serve config. Ang mapping ay ginawa sa foreground at natapos ang prosesong iyon. Patakbuhin muli ang parehong command gamit ang --bg.
Nag-re-resolve ang pangalan pero walang sumasagot. Ang mga serve proxy ay nakaturo sa target na pinangalanan mo, kaya kung walang nakikinig doon, walang mapag-proxy-han. Kumpirmahin gamit ang ss -ltnp | grep 3000 sa parehong machine na nagpapatakbo ng tailscaled. Ang madalas na sanhi nito ay ang isang container na nag-pu-publish ng port nito sa isang Docker bridge address sa halip na 127.0.0.1, na nangangahulugang walang nakikitang listener ang host kung saan mo ito inaasahan. Ipinapakita ng Paano gumagana ang Docker Compose networking kung saan talaga napupunta ang isang published port.
Mga certificate error sa pangalang ts.net. Malamang na hindi naka-enable ang mga HTTPS certificate para sa tailnet. I-on ang mga ito sa admin console, pagkatapos ay patakbuhin ang certificate step nang mag-isa upang hindi humalo ang mga error nito sa output ng serve:
sudo tailscale cert your-host.your-tailnet.ts.netGumagana ang funnel sa mobile data pero iba ang behavior nito kumpara sa laptop mo. Ang laptop mo ay nasa tailnet, kaya nire-resolve ng MagicDNS ang pangalan patungo sa address na 100.x at direktang nararating mo ang serbisyo, nang hindi dumadaan sa relay. Tama ang behavior na iyon, at nangangahulugan ito na hindi kayang i-test ng laptop mo ang public reachability. Gumamit ng curl mula sa isang machine na wala sa tailnet.
FAQ
Ano ang pagkakaiba ng tailscale serve at tailscale funnel?
Depende ito sa kung sino ang makaka-access sa resulta. Ang tailscale serve ay naglalathala ng local port sa isang HTTPS URL na mga device lang sa loob ng iyong tailnet ang makaka-access. Ang tailscale funnel naman ay naglalathala ng parehong port sa isang URL na kahit sino sa internet ay makaka-access, na dumadaan sa mga relay server na pinapatakbo ng Tailscale. Ang mga flag at target ay pareho para sa dalawa. Sasabihin sa iyo ng unang linya ng output kung alin ang nakuha mo: Available within your tailnet o Available on the internet.
Bakit sinasabi ng tailscale funnel na hindi naka-set ang node attribute?
Dahil naka-disable ang funnel para sa isang tailnet hangga't hindi ito ini-enable ng admin. Ang mensahe ay Funnel not available; "funnel" node attribute not set. at nanggagaling ito sa sarili mong client, bago pa man makipag-ugnayan sa anumang relay. Magdagdag ng nodeAttrs entry na nagbibigay ng funnel attribute sa autogroup:member, o sa isang tag kung isang machine lang ang dapat mag-publish, sa loob ng tailnet policy file sa ilalim ng Access Controls. Maaari ring sundan ng isang tailnet admin ang consent URL na ipinapakita ng CLI.
Anong mga port ang maaaring gamitin ng Tailscale Funnel?
443, 8443, at 10000 lang. Ang default ay 443, at maaari kang pumili ng iba gamit ang --https=8443 o --https=10000. Limitasyon ito ng mga funnel relay at hindi ng iyong server, kaya walang pagbabago sa firewall o configuration sa VPS ang makakapag-alis nito. Ang tailscale serve ay walang ganitong restriksyon dahil hindi ito lumalabas sa iyong tailnet.
Mananatili ba ang serve o funnel URL pagkatapos mag-reboot?
Oo, kung ginamit mo ang --bg. Kung wala ito, tatakbo ang command sa foreground, magpi-print ng Press Ctrl+C to exit., at mawawala ang mapping kasabay ng pag-terminate ng proseso. Gamit ang --bg, ang mapping ay isusulat sa serve config ng node at babalik ito kasabay ng tailscaled pagkatapos ng reboot. I-check ito gamit ang tailscale serve status, na magpi-print ng No serve config kung walang naka-set.
Ligtas bang iwanang tumatakbo ang isang funnel?
Ligtas ito sa aspeto ng transport: ang koneksyon ay HTTPS at walang port na nakabukas sa iyong firewall. Hindi ito ligtas sa karaniwang kahulugan dahil public ang URL, kaya public din ang application sa likod nito. Mag-iwan lang ng funnel kung ang nasa likod nito ay may sariling authentication, at i-down ito kapag tapos na ang demo o webhook test gamit ang command na ginamit mo at dagdagan ng off sa dulo.
Mga source para sa behavior ng command sa itaas: ang dokumentasyon ng Tailscale Serve and Funnel at CLI reference sa tailscale.com/docs.