Perlbal supports the concept of reproxying. Basically, this gives it the ability to ask a backend node for a file and get back a specific header that says "this file is really over there, get it there." Perlbal will then load that file or URL and send it to the user transparently, without them ever knowing that they got reproxied to another location. Add the following line to your perlbal.conf to enable reproxying on a per service basis ( reproxying is disabled by default in >= 1.38 ): SET enable_reproxy = true This can be useful for having URLs that get mapped to files on disk without giving users enough information to map out your directory structure. For example, you can create a file structure such as: /home/pics/$userid/$pic Then you can have URLs such as:$userid/picture/$pic When this URL gets passed to the backend web node, it could return a simple response that includes this header: X-REPROXY-FILE: /home/pics/$userid/$pic Perlbal will then use asynchronous IO to send the file to the user without slowing down Perlbal at all. This support also extends to URLs that can be located anywhere Perlbal has access to. It's the same syntax, nearly: X-REPROXY-URL: You can also specify multiple URLs: X-REPROXY-URL: Just specify any number of space separated URLs. Perlbal will request them one by one until one returns a response code of 200. At that point Perlbal will proxy the response back to the user just like normal. Note that the user's headers are NOT passed through to the web server. To the target server, it looks simply like Perlbal is requesting the resource for itself. This behavior may change at some point. One final note: the server that returns the reproxy header can also return a X-REPROXY-EXPECTED-SIZE header. If present, Perlbal will consider a reproxy a failure if the file returned by the target system is of a different size than what the expected size header says. On failure, Perlbal tries the next URI in the list. If it's a file being reproxied, a 404 is returned if the file size is different.