Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I work at an ISP and when a user's credit is zero all HTTP requests NAT to my webserver(Apache 2.2) for payment.

If the user's downloader or autoupdate program is running all those requests come to my webserver and this action causes 75% of Apache's responses to be 404.

I want to limit or cache or drop those requests packets. Does Anyone have a solution? At Apache or firewall or router level.

share|improve this question

closed as not a real question by gWaldo, John Gardeniers, Magellan, Ward, rnxrx Nov 10 '12 at 6:36

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

Why do you care about the 404's? If I understand correctly, you are redirecting random traffic to your http server, so that's to be expected. How about redirecting all traffic to your server's homepage, e.g. with mod_rewrite? Depending on what content you serve and how you do this, apache should already do some caching. – brain99 Aug 26 '12 at 16:30
i care about because all request use resource(cpu & ram). in fact i don't want this request come to apache or if request came,apache use minimum resource for response. redirect isn't good idea in my case. – ooghry Aug 26 '12 at 17:24
How did you implement your captive portal? – Michael Hampton Aug 26 '12 at 17:36
If those 404 requests are sufficient to cause problems then it's time to upgrade your system, or stop over-selling it. I have little sympathy when a cut-cost provider causes problems for themselves. – John Gardeniers Aug 27 '12 at 6:12

There are no good solutions to this problem - Apache needs to process the request in order to present the "Pay Up, Sucker!" page. Anything you do that prevents requests from going to Apache would have to happen at the network layer, at which point your users would no longer be getting the captive portal page and would instead call your helpdesk screaming "ITS BROKEN!"

Frankly you shouldn't care if the captive portal server is chewing up CPU/RAM/whatever -- put the payment page on a dedicated box and let it get beat on. The people who are hitting it are deadbeats and if they have to hit reload a couple of times to get the payment page, so be it.

Also, your payment server probably shouldn't be returning 404s ever -- It should be serving the payment page for any request it receives, regardless of the URL...

share|improve this answer
if someone load in network layer convert to my-ip-server/user-request-path and this path "/user-request-path" does not exist on my webserver and apache return 404 error,i don't want rewrite url and redirect it to /index.php. my real problem is:if only 5,000 user's credit is zero and their downloader downloading 3 url in 3 different connection, 45,000 request per second come to apache and it's cause apache down. – ooghry Aug 27 '12 at 12:34
@ooghry I understand what you're saying. I'm telling you you're doing it wrong - You should not be rewriting any URLs, and you should not be returning any 404 errors (or alternatively your 404 page should be the payment page). If your payment server is undersized and can't handle the load from your deadbeat clients you have two solutions: More/Better payment servers, or booting your deadbeat clients off the network. – voretaq7 Aug 27 '12 at 15:06

few options:

  • use nginx or other 'light' http server with catch-all configuration

  • use iptables-based rate limiting per source ip [keywords for google: iptables hashlimit] and reject or silently drop unwanted percentage of requests and pass only few.

share|improve this answer
The problem with "silently dropping" connections is that it may cause the page to not load the first time (or if the page is all but the simplest flat HTML, may cause parts of the page to fail to load, which could be even worse depending on the page...) – voretaq7 Aug 27 '12 at 15:08
someone said that serving static content is not exactly challenging.. in worst case load can be balanced between few machines. – pQd Aug 27 '12 at 15:22
Serving small static content isn't challenging - that's not my point though. My point is you can't simply "drop a few connections" from a client and expect everything to work. HTTP doesn't work like that - one page may be served over several connections (in parallel or in series), and you can't make a simple packet filter "get it right" all the time. Load balancing across multiple servers is a better solution with less chance of breaking things. – voretaq7 Aug 27 '12 at 15:32
you're right; although.. actually our goal is to break things. in a way. – pQd Aug 27 '12 at 18:27

Not the answer you're looking for? Browse other questions tagged or ask your own question.