docs/production/reverse-proxy.md
When run in production environments, go-ipfs should generally be run behind a reverse HTTP proxy (usually NGINX). You may need a reverse proxy to:
This document contains a collection of tips, tricks, and pitfalls when running a go-ipfs node behind a reverse HTTP proxy.
WARNING: Due to nginx#1293/go-ipfs#6402, parts of the go-ipfs API will not work correctly behind an NGINX reverse proxy as go-ipfs starts sending back a response before it finishes reading the request body. The gateway itself is unaffected.
Go-ipfs gateways behind a single load balancing reverse proxy should use the peering subsystem to peer with each other. That way, as long as one go-ipfs daemon has the content being requested, the others will be able to serve it.
Gateways rarely store content permanently. However, running garbage collection can slow down a go-ipfs node significantly. If you've noticed this issue in production, consider "garbage collecting" by resetting the go-ipfs repo whenever you run out of space, instead of garbage collecting.
This will effectively "garbage collect" without actually running the garbage collector.
TODO:
TODO: Reverse proxies and the subdomain gateway.
TODO: discuss load balancing based on the CID versus the source IP.