Host IP address shows up in links—incorrect HTTPRL config?

I wonder if this issue is related to #2833643: advagg exchanges domain for server ip to link css for anonymous users somehow. Links on the site are showing up with private (10.0.0.0/8) IP addresses of the actual web heads, instead of the correct, externally visible site hostname—occasionally, as I cannot determine the pattern when that happens (edit: see PS1 below). I suspect this is caused by my misunderstanding how to configure HTTPRL in our case. We have a number of Apache servers behind an AWS ELB load balancer. Each has its own unique hostname and it configures its HTTPRL address from its own hostname using a managed setting in Drupal settings.php, as I have assumed—maybe incorrectly—that that would enable it to ensure its callbacks definitely end up on the same host (see attached screenshot).

Should I have configured all the hosts with the same, publicly visible hostname, the one that users see in front of the balancer? It looks like AdvAgg is not too happy about that, and HTTPRL also suggest that the publicly visible hostname should be used.

Changing the HTTPRL setting to the publicly visible hostname stops HTTPRL warning, but the AdvAgg errorr Adv CSS/JS Agg - Self Request Failure HTTP loopback requests to this server are returning a non positive response code of -1004 remains. For what it is worth, hosts file has an entry for both hostnames pointing to loopback addresses and ping confirms that. This does not remedy the issue of private IPs surfacing.

Perhaps others stumbling upon this question will find answers to this question useful when configuring AdvAgg.

PS. 1. It seems that the private IPs only surface (but not always) in sections of the site that are generated using a block that displays them in a jQuery accordion using this code:

function botticelli_zen_preprocess_block(&$vars) {
  drupal_add_library('system', 'ui.accordion');
  drupal_add_js('jQuery(document).ready(function(){jQuery("#accordion").accordion({icons: { "header": "ui-icon-plus", "activeHeader": "ui-icon-minus" },heightStyle: "content", animate:500, active:false,collapsible:true});});', 'inline');
}

2. Setting $base_url to the publicly visible hostname fixes the issue, I think (more testing needed)—but that is a workaround, as setting $base_url only papers over an uderlying issue. I would like to solve it, if possible, please.