罗泽轩

@blinkseb Sorry, I missed something in my previous answer. It seems that Nginx doesn't allow to set the real ip twice: https://github.com/nginx/nginx/blob/master/src/http/modules/ngx_http_realip_module.c#L152 So change the `X-Forwarded-For` in the middle could...

@blinkseb > Any chance it's supported natively by openresty Maybe something else depends on `Nginx doesn't allow to set the real ip twice` to work correctly. So hack the Nginx...

> @blinkseb > > > Any chance it's supported natively by openresty > > Maybe something else depends on `Nginx doesn't allow to set the real ip twice` to work...

A weird problem. The `spawn_checker` is expected to be called once, which will tick a new timer at constant interval. Do you call this method multiple times?

Three questions: 1. I am not sure if it's a good idea to change the return values from `ok, err` to `ctx, reused|err`. 2. Maybe we need a new API...

@phillipp A SSL handshake (happened with connection level) may be related with multiple HTTP requests. Therefore you can't simply `leave` the limit in `log_by_lua` even `ngx.ctx` is available.

It is possible to limit the request number in ssl_certificate_by_lua, but it is not possible to limit the connection number as there is no way to decrease the counter when...

Does this new method have any advantage over running multiple coroutines (created by `ngx.thread.spawn`, each one contains their own sockets) and sync with `ngx.semaphore`? The latter one is already battle-tested.

@GuyLewin You can use the example in `ngx.semaphore` docs as a start: https://github.com/openresty/lua-resty-core/blob/master/lib/ngx/semaphore.md Personally speaking, I think the coroutines could be cheap enough. And implementing a new layer of I/O...

Actually there are some unofficial clients offer part of the redis-cluster support. For example, like this one: https://github.com/steve0511/resty-redis-cluster