Global network services
IP addresses
Fly applications have dedicated IP addresses. Each application starts with two addresses — one IPv6 and one IPv4. IPv6 addresses are free, global IPv4 addresses are billed monthly.
Anycast
We announce global IP blocks from all of our datacenters ovef BGP, otherwise known as anycast. Anycast is a core internet routing mechanism that connects clients to the "nearest" server advertising a block of IPs. You can read all about it on Wikipedia.
TCP services
Global service listeners are defined in the fly.toml
config file.
This is the default service configuration:
[[services]]
internal_port = 8080
protocol = "TCP"
[services.port.80]
handlers = ["HTTP"]
[services.port.443]
handlers = ["TLS", "HTTP"]
services.port.<num>
Defines which external ports you want Fly to accept traffic on. You can configure an application to listen for global traffic on ports 80, 443, 5000, and ports 10000 - 10100.
services.port.<num>.handlers
Applies connection middleware to incoming connections before forwarding to the application.
services.internal_port
Specifies which internal application port Fly should forward traffic to.
Connection handlers
The handlers
config setting specifies which middleware applies to incoming TCP connections. Use these to convert TCP connections into something your application can handle.
TLS
The TLS
middleware terminates TLS using Fly managed application certificates, then forwards a plaintext connection to the application process. This is useful for running TCP services and offloading TLS
to the Fly proxy.
For performance purposes, the Fly proxy will terminate TLS on the host a client connects to, and then forward the connection to the nearest available application instance.
Note: the TLS
handler includes ALPN negotiation for HTTP/2. When possible, applications will connect to these kinds of Fly services using HTTP/2, and we will forward an unencrypted HTTP/2 connection (h2c
) to the application process.
HTTP
Many applications have limited HTTP support, the HTTP
middleware normalizes HTTP connections and sends HTTP 1.1 requests to the application process. This is roughly how nginx
and other reverse proxies work, and allows your application to globally accept modern HTTP protocols (like HTTP/2) without extra complexity.
If your application stack has good HTTP/2 support (like Go), you will get better performance accepting TCP connections directly, and using the TLS handler to terminate SSL. Your application does need to understand h2c
for this to work, however.
The HTTP handler adds a number of standard HTTP headers to requests, and a few Fly specific headers for convenience:
Header | Description |
---|---|
FLY_CLIENT_IP | The IP address Fly accepted a connection from |
X_FORWARDED_FOR | A comma separated list of proxy servers the request passed through. MDN has full documentation for this header |
X_FORWARDED_PROTO | Original client protocol, either http or https |
X_FORWARDED_SSL Indicates if client connected over SSL, either on or off | |
X_FORWARDED_PORT | Original connection port, header may be set by client |
FLY_FORWARDED_PORT | Original connection port, always set by Fly |
TCP pass through
If you don't specify handlers, we just forward TCP to your application as is. This is useful if you want to handle TLS termination yourself, for example.
Proxy protocol
The proxy_proto
handler adds information about the original connection, including client IP + port and server IP + port (from the client's perspective). Most applications need additional logic to accept the proxy protocol, either using a prebuilt library or implementing the proxy protocol directly.