Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
Cloudflare Tunnel baut ausgehende Verbindungen vom Origin zu Cloudflare auf. Das reduziert Inbound-Exposure, aber Access Policies, Origin-Firewall, Connector-Redundanz und serverinitiierter Traffic müssen separat geplant werden.
Laut aktueller Cloudflare-Doku baut `cloudflared` einen Outbound-only Tunnel vom Origin/Privatnetz zu Cloudflare. Public-App-Traffic läuft über Cloudflare; für private Netze kommen Routes und Zero-Trust-Policies hinzu.
cloudflared hält einen persistenten Outbound-Tunnel. Nutzertraffic läuft über Cloudflare Edge Policy/WAF und wird durch den Tunnel zum privaten Service proxied.
Public Hostnames veröffentlichen Apps ohne direkte Origin-Exposure. Private Networking verbindet Clients per CIDR-/Hostname-Routes mit internen Services.
Für kritische Origins bieten mehrere Connectoren auf unterschiedlichen Hosts/Failure Domains mehr Resilienz.
Befehle unterscheiden sich je lokal/remote gemanagtem Tunnel; an eigenes Modell anpassen.
Türkei (Türkisch)
Germany (German)
Worldwide (English)
cloudflared --versionsystemctl status cloudflared --no-pagerjournalctl -u cloudflared --since '-15 min' --no-pagerss -lntup | grep cloudflared || truecloudflared tunnel list 2>/dev/null || trueApp-Publishing, Private-Subnet-Zugriff und Site-to-Site-Traffic getrennt bewerten.
Outbound Connector
Peer-to-Peer Subnet
Firewall/TLS-Kontrolle
Keine direkte Public-Inbound-Exposure nötig; cloudflared verbindet outbound. Internet-Outbound zu Cloudflare ist erforderlich.
Für manche Private-App/Network-Access-Fälle ja; Site-to-Site und serverinitiierter Traffic unterscheiden sich.
Nein. cloudflared proxyt User→Service-Traffic; Server→Internet nutzt normale Routing-Tabelle.
Teilen Sie Services, private Subnetze, Nutzergruppen und HA-Bedarf; Cloudflare Tunnel, WireGuard oder Hybridmodell auswählen.