Could you please post one of the <Location> sections you modified?
Also, where did you modify? The pagespeed.conf file or a .htaccess file?

I modified pagespeed.conf and added lan addresses.

    <Location /mod_pagespeed_statistics>
        Order allow,deny
        Allow from localhost
        Allow from 127.0.0.1
        Allow from 192.168.100.0/24
        SetHandler mod_pagespeed_statistics
    </Location>
    <Location /mod_pagespeed_console>
        Order allow,deny
        Allow from localhost
        Allow from 127.0.0.1
        Allow from 192.168.100.0/24
        SetHandler mod_pagespeed_console
    </Location>
    <Location /mod_pagespeed_message>
        Allow from localhost
        Allow from 127.0.0.1
        Allow from 192.168.100.0/24
        SetHandler mod_pagespeed_message
    </Location>
    <Location /mod_pagespeed_referer_statistics>
        Allow from localhost
        Allow from 127.0.0.1
        Allow from 192.168.100.0/24
        SetHandler mod_pagespeed_referer_statistics
    </Location>

OK, with a very simple Apache setup this works fine for me.

What other directives do you have in your httpd.conf and/or pagespeed.conf 
files that refer to 192.168.100.0? It looks like someone somewhere is 
redirecting your requests with a 301 response.

Another directive which related to 192.168.100.0 would be the mod_rewrite rule 
below.

---- being ----
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress
---- end ----
This is written in a .htaccess file generated by WordPress.

I'm not sure about other directives.  The below is the list of conf files.  Are 
there interesting conf files?
actions.conf          cache.load    expires.load      proxy.load
actions.load          cgi.load      fastcgi.conf      proxy_ajp.load
alias.conf            cgid.conf     fastcgi.load      reqtimeout.conf
alias.load            cgid.load     info.conf         reqtimeout.load
auth_basic.load       dav.load      info.load         rewrite.conf
authn_file.load       dav_svn.conf  mime.conf         rewrite.load
authz_default.load    dav_svn.load  mime.load         setenvif.conf
authz_groupfile.load  deflate.conf  negotiation.conf  setenvif.load
authz_host.load       deflate.load  negotiation.load  ssl.conf
authz_svn.load        dir.conf      pagespeed.conf    ssl.load
authz_user.load       dir.load      pagespeed.load    status.conf
autoindex.conf        env.load      perl.conf         status.load
autoindex.load        expires.conf  perl.load

How does that rewrite rule relate to 192.168.100.0? I confess I know very 
little about mod_rewrite.

Perhaps you could do 'grep -r 192.168.100 .' after cd'ing to your conf 
directory?

The rewrite rule is FYI.  It might not relate to this issue.

Another directive which refer to 192.168.100.0/24 was status.conf.
---- begin ----
<IfModule mod_status.c>
#
# Allow server status reports generated by mod_status,
# with the URL of http://servername/server-status
# Uncomment and change the "192.0.2.0/24" to allow access from other hosts.
#
<Location /server-status>
    SetHandler server-status
    Order allow,deny
    Allow from localhost
    Allow from 127.0.0.1
    Allow from 192.168.100.0/24
</Location>

# Keep track of extended status information for each request
ExtendedStatus On

# Determine if mod_status displays the first 63 characters of a request or
# the last 63, assuming the request itself is greater than 63 chars.
# Default: Off
#SeeRequestTail On


<IfModule mod_proxy.c>
    # Show Proxy LoadBalancer status in mod_status
    ProxyStatus On
</IfModule>


</IfModule>
---- end ----
The other directives don't have 192.168.100.

Could you please try using wget (or curl) to fetch the page?
IIRC wget reports redirects so that might be useful data.
Something like this on the 192.168.100.x machine should do it:
wget -S -O /dev/null http://servername/mod_pagespeed_console

Oh, and does /mod_pagespeed_statistics work? You didn't list it in your 
original report.

After I added a directive to distable mod_rewrite, all the pages 
(/mod_pagespeed_console, /mod_pagespeed_message, 
/mod_pagespeed_referer_statistics and /mod_pagespeed_statistics) became to work 
correctly.  The directive I added was:
---- begin ---
        <IfModule mod_rewrite.c>
            RewriteEngine Off
        </IfModule>
---- end ----

The whole pagespeed.conf is:
---- begin ----
<IfModule pagespeed_module>
    ModPagespeed on
    ModPagespeedInheritVHostConfig on
    AddOutputFilterByType MOD_PAGESPEED_OUTPUT_FILTER text/html
    ModPagespeedFileCachePath            "/var/cache/mod_pagespeed/"
    ModPagespeedFileCacheInodeLimit        500000
    ModPagespeedAvoidRenamingIntrospectiveJavascript on
    ModPagespeedLibrary 43 1o978_K0_LNE5_ystNklf http://www.modpagespeed.com/rewrite_javascript.js
    <Location /mod_pagespeed_beacon>
        <IfModule mod_rewrite.c>
            RewriteEngine Off
        </IfModule>

          SetHandler mod_pagespeed_beacon
    </Location>

    <Location /mod_pagespeed_statistics>
        <IfModule mod_rewrite.c>
            RewriteEngine Off
        </IfModule>

        Order allow,deny
        Allow from localhost
        Allow from 127.0.0.1
    Allow from 192.168.100.0/24
        SetHandler mod_pagespeed_statistics
    </Location>

    <Location /mod_pagespeed_console>
        <IfModule mod_rewrite.c>
            RewriteEngine Off
        </IfModule>

        Order allow,deny
        Allow from localhost
        Allow from 127.0.0.1
    Allow from 192.168.100.0/24
        SetHandler mod_pagespeed_console
    </Location>

    ModPagespeedMessageBufferSize 100000

    <Location /mod_pagespeed_message>
        <IfModule mod_rewrite.c>
            RewriteEngine Off
        </IfModule>

        Allow from localhost
        Allow from 127.0.0.1
    Allow from 192.168.100.0/24
        SetHandler mod_pagespeed_message
    </Location>
    <Location /mod_pagespeed_referer_statistics>
        <IfModule mod_rewrite.c>
            RewriteEngine Off
        </IfModule>

        Allow from localhost
        Allow from 127.0.0.1
    Allow from 192.168.100.0/24
        SetHandler mod_pagespeed_referer_statistics
    </Location>
</IfModule>
---- end ----

> wget -S -O /dev/null http://servername/mod_pagespeed_console
Does this still needed for debugging?  If so, I will try it.

My hope is that the wget will tell me what redirections are occurring so if 
it's easy it would be good if you can do it.

What mod_rewrite rules have you setup? Presumably something that redirects 
/mod_pagesped_*.

The log of wget was below.  Sorry for Japanese output.
---- begin ----
nodchip@gilgamesh ~ % wget -S -O /dev/null
http://192.168.100.2/mod_pagespeed_co
nsole
--2013-01-11 21:55:46--  http://192.168.100.2/mod_pagespeed_console
192.168.100.2:80 に接続しています... 接続しました。
HTTP による接続要求を送信しました、応答を待っています...
  HTTP/1.1 500 Internal Server Error
  Date: Fri, 11 Jan 2013 12:55:40 GMT
  Server: Apache/2.2.22 (Ubuntu)
  Vary: Accept-Encoding
  Content-Length: 616
  Connection: close
  Content-Type: text/html; charset=iso-8859-1
2013-01-11 21:55:46 エラー 500: Internal Server Error。
---- end ----

The mod_rewrite rules that I have setup was in the comment #6.  They were all.

Thanks, that's useful (and the Japanese doesn't matter :).

Given that it's a 500 error I would expect some error message(s) in the Apache 
error_log file. Could you please repeat the wget and check the log file for any 
new messages that the wget generated?

Thanks, m.

The error log in apache error.log was:

---- begin ----
[Wed Jan 16 23:24:22 2013] [error] [client 192.168.100.7] Request exceeded the 
limit of 10 internal redirects due to probable configuration error. Use 
'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel 
debug' to get a backtrace.
---- end ----
I tried to get more detail log by adding 'LogLevel debug' but I could not 
understand where to add the option.  Where is the right place to add 'LogLevel 
debug'?

In httpd.conf there's a LogLevel directive. Change that to debug (it's probably 
warn now). But, to be honest, I doubt that it will provide any more info.

Not sure, if I can join in this conversation. I've been searching for a 
solution on the same issue in a default CentOS and Ubuntu installation.

Firstly, thanks for reporting the issue and possible work around (with 
RewriteEngine off). I'm not sure, if the issue is related to mod_pagespeed or 
WordPress rewrites.

Inserting following line in the rewrite rules for WordPress solved the issue 
for me. ( tip from http://stackoverflow.com/a/4101768/1004587 )

RewriteCond %{REQUEST_URI} !^/mod_pagespeed_[a-z_]+$

Here is the whole rewrite section in my virtualhost for that specific domain...

    <Directory "/path/to/wordpress/core/files">
        Options Indexes FollowSymLinks MultiViews
        AllowOverride None
        Order allow,deny
        allow from all

        <IfModule mod_rewrite.c>
            RewriteEngine On
            RewriteBase /
            RewriteRule ^index\.php$ - [L]
            RewriteRule ^server-status$ - [L]
            # do not parse mod_pagespeed URIs
            RewriteCond %{REQUEST_URI} !^/mod_pagespeed_[a-z_]+$
            RewriteCond %{REQUEST_FILENAME} !-f
            RewriteCond %{REQUEST_FILENAME} !-d
            RewriteRule . /index.php [L]
        </IfModule>
    </Directory>

I thought I could share this here, hoping it'd help to see where the issue is.

Thanks,
Pothi

The only way to make this work is to have a virtual host to use for 
mod_pagespeed statistics and add RewriteEngine Off to that virtual host config.

Or use the solution from Pothi.

The reason the wordpress style rewrite rules mess with mod_pagespeed_statistics 
is because the rewrite rules check if a file or directory exist by that name, 
and if not redirect the request to /index.php

Another solution would be to create empty files called 
mod_pagespeed_statistics/... in the web root. Although that would just be a 
workaround as well.

This is not a bug in mod_pagespeed in my opinion.

I am having the same issue as described above on mod_pagespeed/1.4.26.2-2759.

I believe the problem lies in where mod_pagespeed intercepts the stats_url 
request in the order of other processing. If this is not done early on, 
mod_rewrite or other Apache handlers may decide to do something else with the 
"non-existent" url for stats.

Luci

Even if it's not our bug, it sounds like we could avoid this with the

        <IfModule mod_rewrite.c>
            RewriteEngine Off
        </IfModule>

snippet. We should add that to the default config.

IMHO, slig's argument is right. The bug/problem isn't coming from pagespeed, 
I've try to reproduce the errors, I'm using nginx as reverse proxy and load 
balancer, just put this directive :

----
location /mod_pagespeed_statistics {
      proxy_pass http://pagespeed_host;
}
----

And the pagespeed should allow the remote host, (eg. my remote IP is 
103.xx.yy.236)
----
    <Location /mod_pagespeed_statistics>
        Order allow,deny
        Allow from localhost
        Allow from 127.0.0.1
        Allow from 103.xx.yy.236/29
        SetHandler mod_pagespeed_statistics
    </Location>
----

The configuration above is works fine for me.
My pagespeed version is 1.3.25.4-2630

1.4.26.2-2759 on Ubuntu 12.10 x64 with apache 2.2.22

While troubleshooting this I'm using 'Allow from all' just to exclude host 
being denied access issues. I've tried everything suggested here and elsewhere 
to no avail. Even tried the empty files trick.

I also use a CMS like most other people here that has its own redirect rules. 
The only thing that got it working is when I emptied the root folder, all 
/mod_pagespeed_* pages display just fine (but of course then I had no CMS).

While I'd agree that this whole issue is not exactly a pagespeed bug per se, it 
still is a compatibility issue with a lot of widely used CMSes out there. So, 
sure we could ignore this altogether or we could file separate issues against 
each CMS or web app out there to account for this and wash our hands off of it.

What I suggest though is we solve this by providing our own admin web UI as an 
separate, alternative package. How about it?

# if pagespeed_admin or pagespeed_global_admin exist go directly to it 
RewriteCond %{REQUEST_URI} !/pagespeed_admin
RewriteCond %{REQUEST_URI} !/pagespeed_global_admin

<IfModule mod_rewrite.c>
RewriteEngine on

# if a directory or a file exists, use it directly
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond $1 !^(index\.php)

# if pagespeed_admin or pagespeed_global_admin exist go directly to it 
RewriteCond %{REQUEST_URI} !/pagespeed_admin
RewriteCond %{REQUEST_URI} !/pagespeed_global_admin

# otherwise forward it to index.php
RewriteRule ^(.*)\?*$ index.php/$1 [L,QSA]
</IfModule>

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

# if pagespeed_admin or pagespeed_global_admin exist go directly to it
RewriteCond %{REQUEST_URI} !/pagespeed_admin
RewriteCond %{REQUEST_URI} !/pagespeed_global_admin

RewriteRule . /index.php [L]
</IfModule>

# END WordPress

######## PAGESPEED #############
<IfModule pagespeed_module>
ModPagespeed on
ModPagespeedRunExperiment off
ModPagespeedAnalyticsID UA-xxxxxx
ModPagespeedFileCachePath "/var/cache/mod_pagespeed/"
ModPagespeedCacheFragment yourDomain
ModPagespeedEnableFilters add_instrumentation
ModPagespeedReportUnloadTime on
</IfModule>

run_rewritemap_programs(server_rec *s , apr_pool_t *p){
if (conf->state == ENGINE_DISABLED) { // usage of "RewriteEngine"
  return APR_SUCCESS; // early return
rewritemap_program(...); // usage of "RewriteRule" 
}