Перехват html, генерируемого web-сервером перед отправкой

• Обратный прокси: направляйте все запросы, поступающие на nginx, на PHP-скриптик (на отдельном вебсервере или прямо в nginx через php-fpm). Он должен будет отправлять поступивший ему запрос в неизменном* виде к реальному приложению посредством любого HTTP-клиента, например curl. Соответственно, из HTTP-клиента вы получите весь ответ: статус, заголовки и тело. Можете сделать с ними что угодно и отправить их в качестве собственного ответа после доработки.
• Rack-прослойка (middleware): на уровне Ruby on Rails (а точнее Rack, на котором он построен) можно добавить наружную функцию-прослойку, которая получит исходный запрос к приложению, передаст его глубже и получит ответ от приложения, но для отправки клиенту сможет сформировать собственный ответ (на Ruby, естественно; но из Ruby можно вызывать и другие программы, если нужно; а может, логику замены лучше написать на Ruby?).
  • Пример Rack-прослойки
  • Rack-прослойки в Ruby on Rails
• Сделать по-нормальному: сделать замену в исходном коде приложения на Ruby on Rails и не городить таких жутких костылей с перерасходом ресурсов.

* Хотя какие-то изменения внести вам всё-таки придётся и/или захочется, например про IP-адрес или наличие SSL. Во вступлении RFC 7239 описан существующий де-факто стандарт общения с обратным прокси. Именно вступлении! Новый подход, предлагаемый этим RFC, я на практике пока не встречал.