# 2.0 new option: do-resolve problems

**URL:** <https://discourse.haproxy.org/t/2-0-new-option-do-resolve-problems/4111>\
**Category:** Help!\
**Created:** [July 30, 2019, 7:32pm UTC](https://discourse.haproxy.org/t/2-0-new-option-do-resolve-problems/4111 "2019-07-30T19:32:10Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![yick](https://avatars.discourse-cdn.com/v4/letter/y/e0b2c6/32.png) [@yick](https://discourse.haproxy.org/u/yick)\
**Post date:** [July 30, 2019, 7:32pm UTC](https://discourse.haproxy.org/t/2-0-new-option-do-resolve-problems/4111/1 "2019-07-30T19:32:10Z")

</div>

```
frontend fe
    bind 10.0.0.1:3128 transparent
    mode tcp
    tcp-request content do-resolve(txn.myip,mydns,ipv4) req.hdr(host),lower
    default_backend be

backend be
    tcp-request content reject if { var(txn.myip) -m ip 127.0.0.0/8 10.0.0.0/8 }
    tcp-request content set-dst var(txn.myip)
    server clear 0.0.0.0:0

```

Here are 2 problems:

1. if ipv6 is prefered instead ipv4, in backend 0.0.0.0:0 cannot handle this case.
2. Because var(txn.myip) is randomly selected, is it still possible to use “source IP affinity” to keep session persistent? E.g. client 10.0.0.2 connects to [example.com](http://example.com)(IP1,IP2,IP3). Within 2.0.3 version, all 3 IPs would be load-balanced, but in fact only one of them should be picked up.

---

<div class="post-metadata">

**Author:** ![lukastribus](https://avatars.discourse-cdn.com/v4/letter/l/7ea924/32.png) [@lukastribus](https://discourse.haproxy.org/u/lukastribus)\
**Post date:** [July 30, 2019, 7:38pm UTC](https://discourse.haproxy.org/t/2-0-new-option-do-resolve-problems/4111/2 "2019-07-30T19:38:17Z")

</div>

You are trying to do something that haproxy is not build for. haproxy is not a forward proxy, you’d by spending a lot of time figuring out a working configuration which in the end would be discouraged and unsupported.

I suggest you look for a real forward proxy instead. Take a look at tinyproxy for example.

---

<div class="post-metadata">

**Author:** ![yick](https://avatars.discourse-cdn.com/v4/letter/y/e0b2c6/32.png) [@yick](https://discourse.haproxy.org/u/yick)\
**Post date:** [July 31, 2019, 4:32am UTC](https://discourse.haproxy.org/t/2-0-new-option-do-resolve-problems/4111/3 "2019-07-31T04:32:31Z")

</div>

Thanks for your remind. In terms of CPU/RAM efficiency, Haproxy outperforms a lot. Let alone versatile combinations of frontends and backends. Even if it binded to 10.0.0.1:80/443, sessions persistence with backends would still be concerned. E.g. All 3IPs servers the same HTTP video streamings, while different keys are provisioned to deciper contents for each session. Hence I suppose they will not be corner cases sometimes.

---

<div class="post-metadata">

**Author:** ![lukastribus](https://avatars.discourse-cdn.com/v4/letter/l/7ea924/32.png) [@lukastribus](https://discourse.haproxy.org/u/lukastribus)\
**Post date:** [July 31, 2019, 6:49am UTC](https://discourse.haproxy.org/t/2-0-new-option-do-resolve-problems/4111/4 "2019-07-31T06:49:22Z")

</div>

Sessions persistence works per server, it’s impossibile for it to work if the servers are not configured. This will never work and haproxy is not designed for this.

---

<div class="post-metadata">

**Author:** ![yick](https://avatars.discourse-cdn.com/v4/letter/y/e0b2c6/32.png) [@yick](https://discourse.haproxy.org/u/yick)\
**Post date:** [July 31, 2019, 9:52am UTC](https://discourse.haproxy.org/t/2-0-new-option-do-resolve-problems/4111/5 "2019-07-31T09:52:32Z")

</div>

OK, I see. 😅 Haproxy will not hash/stick variable destinations, the same as NGINX.

---

<div class="post-metadata">

**Author:** ![yick](https://avatars.discourse-cdn.com/v4/letter/y/e0b2c6/32.png) [@yick](https://discourse.haproxy.org/u/yick)\
**Post date:** [July 31, 2019, 2:31pm UTC](https://discourse.haproxy.org/t/2-0-new-option-do-resolve-problems/4111/6 "2019-07-31T14:31:22Z")

</div>

Please forgive me. I still cannot understand the problem 1, i.e. access from IPV4 to IPV6. In my opinion, “0.0.0.0:0” won’t be able to deal with IPV6.

---

<div class="post-metadata">

**Author:** ![lukastribus](https://avatars.discourse-cdn.com/v4/letter/l/7ea924/32.png) [@lukastribus](https://discourse.haproxy.org/u/lukastribus)\
**Post date:** [July 31, 2019, 3:10pm UTC](https://discourse.haproxy.org/t/2-0-new-option-do-resolve-problems/4111/7 "2019-07-31T15:10:23Z")

</div>

Yes, I doubt set-dst can handle both address families. I suggest you file a bug on github.