On 27/02/11 05:46, Jack Engqvist Johansson wrote:
> Hi, I got my reverse proxy to work now. But I got one problem:
>
> It only caches images (png/jpg). If i look at the access.log I see TCP_MISS/200.
> Whats wrong with my configuration?
>
> Thanks in advance, Jack
>
> access.log:
> 1298738665.393 1 93.182.143.156 TCP_MISS/304 242 GET
> http://demo.nectos.org:8000/admin/management.js -
> FIRST_UP_PARENT/nectrussquid -
> 1298738671.567 1 93.182.143.156 TCP_MISS/200 5630 GET
> http://demo.nectos.org:8000/admin/management.js -
> FIRST_UP_PARENT/nectrussquid application/x-javascript
> 1298738677.343 1 93.182.143.156 TCP_MISS/200 5630 GET
> http://demo.nectos.org:8000/admin/management.js -
> FIRST_UP_PARENT/nectrussquid application/x-javascript
>
>
> squid.conf:
>
> http_port 80 accel vport=8000 vhost act-as-origin
> cache_peer localhost parent 8000 0 no-query originserver name=nectrussquid
> acl oursites dstdomain .nectrus.com .tekulturen.se .cust.relakks.com
> acl all2 src 0.0.0.0/0.0.0.0
Why is "all2" defined like this?
> cache_peer_access nectrussquid allow all2
Deflating "all2" back to its equivalent "all". This is the same as
"allow all" to the peer.
Where I think you want "allow oursites" to the peer.
> http_access allow all
"allow all" allows the entire Internet.
If you have altered "all" then undo that quickly, there are security
settings depending on it really matching *all* possible global machines.
The http_access lines below "allow all" will not be checked.
IMO you should remove the lines with "allow all" above and the "allow
all2" below.
> http_access allow all2
> http_access allow oursites
>
> acl cache_html rep_mime_type text/html text/css text/javascript
> image/png image/jpeg application/xhtml+xml application/xml text/plain
> application/x-javascript application/javascript
> acl javascript rep_mime_type -i ^application/x-javascript$
> no_cache deny cache_html
"no_cache" is an old way of writing "cache". We tell people to remove
the "no_" part to make it clearer what the rule actually does.
One guess what "cache deny cache_html" does to HTML pages?
> no_cache deny javascript
Same for "cache deny javascript" ?
The above two lines are your caching problem and SHOULD be erased.
> cache allow all
Again, "allow all" always matches. So the other rules are not doing
anything. You can erase the two lines below:
> cache allow javascript
> cache allow cache_html
>
> http_reply_access allow cache_html
> http_reply_access allow javascript
Doing reply access on a reverse-proxy is highly weird and extremely
rarely needed. If you allow access to the private backend server, why
would you block the response going back?
I think you can/should remove these http_reply_access lines.
> never_direct allow all
>
> cache_mem 100 MB
>
> # change below to match your hostname (used in logs as host)
> visible_hostname nectrus.com
>
> #cache_store_log none
>
> refresh_pattern -i \.php$ 0 50% 420 ignore-no-cache
> override-expire ignore-private override-lastmod
> refresh_pattern -i \.jpg$ 10 90% 42000 ignore-no-cache
> override-expire ignore-private override-lastmod
> refresh_pattern -i \.gif$ 0 50% 420
> refresh_pattern -i \.png$ 10 90% 42000 ignore-no-cache
> override-expire ignore-private override-lastmod
> refresh_pattern -i \.js$ 0 90% 4200 ignore-no-cache
> override-expire ignore-private override-lastmod
> refresh_pattern -i \.htm$ 0 20% 420
> refresh_pattern -i \.html$ 0 20% 4200 ignore-no-cache
> override-expire ignore-private override-lastmod
> refresh_pattern -i \.css$ 50 100% 7200 ignore-no-cache
> override-expire ignore-private override-lastmod
Um, you run the backend web server yes?
So you control whether Apache sends the headers being overridden here.
Doing the override will cause just as many problems in your own cache as
disobeying them will cause down the line in the visitors caches.
Check your HIT/MISS after *all* of the above changes are made. Your
reverse proxy will then be operating in a simpler manner we can assist
deeper debugging on should the problem persist.
Amos
-- Please be using Current Stable Squid 2.7.STABLE9 or 3.1.11 Beta testers wanted for 3.2.0.5Received on Sun Feb 27 2011 - 05:02:10 MST
This archive was generated by hypermail 2.2.0 : Sun Feb 27 2011 - 12:00:03 MST