| 1 | # IPFS & Reverse HTTP Proxies |
| 2 | |
| 3 | When run in production environments, go-ipfs should generally be run behind a |
| 4 | reverse HTTP proxy (usually NGINX). You may need a reverse proxy to: |
| 5 | |
| 6 | * Load balance requests across multiple go-ipfs daemons. |
| 7 | * Cache responses. |
| 8 | * Buffer requests, only releasing them to go-ipfs when complete. This can help |
| 9 | protect go-ipfs from the |
| 10 | [slowloris](https://en.wikipedia.org/wiki/Slowloris_(computer_security) |
| 11 | attack. |
| 12 | * Block content. |
| 13 | * Rate limit and timeout requests. |
| 14 | * Apply QoS rules (e.g., prioritize traffic for certain important IPFS resources). |
| 15 | |
| 16 | This document contains a collection of tips, tricks, and pitfalls when running a |
| 17 | go-ipfs node behind a reverse HTTP proxy. |
| 18 | |
| 19 | **WARNING:** Due to |
| 20 | [nginx#1293](https://trac.nginx.org/nginx/ticket/1293)/[go-ipfs#6402](https://github.com/ipfs/go-ipfs/issues/6402), |
| 21 | parts of the go-ipfs API will not work correctly behind an NGINX reverse proxy |
| 22 | as go-ipfs starts sending back a response before it finishes reading the request |
| 23 | body. The gateway itself is unaffected. |
| 24 | |
| 25 | ## Peering |
| 26 | |
| 27 | Go-ipfs gateways behind a single load balancing reverse proxy should use the |
| 28 | [peering](../config.md#peering) subsystem to peer with each other. That way, as |
| 29 | long as one go-ipfs daemon has the content being requested, the others will be |
| 30 | able to serve it. |
| 31 | |
| 32 | # Garbage Collection |
| 33 | |
| 34 | Gateways rarely store content permanently. However, running garbage collection |
| 35 | can slow down a go-ipfs node significantly. If you've noticed this issue in |
| 36 | production, consider "garbage collecting" by resetting the go-ipfs repo whenever |
| 37 | you run out of space, instead of garbage collecting. |
| 38 | |
| 39 | 1. Initialize your gateways repo to some known-good state (possibly pre-seeding |
| 40 | it with some content, a config, etc.). |
| 41 | 2. When you start running low on space, for each load-balanced go-ipfs node: |
| 42 | 1. Use the nginx API to set one of the upstream go-ipfs node's to "down". |
| 43 | 2. Wait a minute to let go-ipfs finish processing any in-progress requests |
| 44 | (or the short-lived ones, at least). |
| 45 | 3. Take the go-ipfs node down. |
| 46 | 4. Rollback the go-ipfs repo to the seed state. |
| 47 | 5. Restart the go-ipfs daemon. |
| 48 | 6. Update the nginx config, removing the "down" status from the node. |
| 49 | |
| 50 | This will effectively "garbage collect" without actually running the garbage |
| 51 | collector. |
| 52 | |
| 53 | # Content Blocking |
| 54 | |
| 55 | TODO: |
| 56 | |
| 57 | * Filtering requests |
| 58 | * Checking the X-IPFS-Path header in responses to filter again after resolving. |
| 59 | |
| 60 | # Subdomain Gateway |
| 61 | |
| 62 | TODO: Reverse proxies and the subdomain gateway. |
| 63 | |
| 64 | # Load balancing |
| 65 | |
| 66 | TODO: discuss load balancing based on the CID versus the source IP. |