[GH-ISSUE #3078] [Feature Request] Prefer IPv6/AAAA for DNS resolution.

gitea-mirror commented

2026-05-05 13:35:10 -06:00

Owner

Copy link

Originally created by @fernvenue on GitHub (Aug 28, 2022).
Original GitHub issue: https://github.com/fatedier/frp/issues/3078

Describe the feature request

Hi, I'm using frp for HTTP/HTTPS reverse proxy, and I just found out that when I use a domain name instead of IP address in local_ip, frp will always request A type first, please tell me how can I prefer IPv6 in frp? If we can't, could you please add a feature like prefer_ipv6 or disable_ipv4 for each proxy connection, so we can make frp use IPv6 first?

Describe alternatives you've considered

Actually I have tried to use a IPv6 only address like ipv6.icanhazip.com, but unfortunately, frp will still request A type first, and sometime frp will get i/o time out when DNS server return nothing for A type request :(

Affected area

Docs
Installation
Performance and Scalability
Security
User Experience
Test and Release
Developer Infrastructure
Client Plugin
Server Plugin
Extensions
Others

Originally created by @fernvenue on GitHub (Aug 28, 2022). Original GitHub issue: https://github.com/fatedier/frp/issues/3078 ### Describe the feature request Hi, I'm using frp for HTTP/HTTPS reverse proxy, and I just found out that when I use a domain name instead of IP address in `local_ip`, frp will always request A type first, please tell me how can I prefer IPv6 in frp? If we can't, could you please add a feature like `prefer_ipv6` or `disable_ipv4` for each proxy connection, so we can make frp use IPv6 first? ### Describe alternatives you've considered Actually I have tried to use a IPv6 only address like `ipv6.icanhazip.com`, but unfortunately, frp will still request A type first, and sometime frp will get i/o time out when DNS server return nothing for A type request :( ### Affected area - [ ] Docs - [ ] Installation - [X] Performance and Scalability - [ ] Security - [X] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [ ] Client Plugin - [ ] Server Plugin - [ ] Extensions - [X] Others

gitea-mirror

2026-05-05 13:35:10 -06:00

closed this issue
added the
lifecycle/stale
label

gitea-mirror commented

2026-05-05 13:35:12 -06:00

Author

Owner

Copy link

@fernvenue commented on GitHub (Aug 28, 2022):

By the way, here's another problem, does frp have cache for DNS?

My DNS server got 166000+ requests from frp just in 7 days, I don't know why frp need this, send requests for every connection is a terrible idea I think, can't we use cache? Or maybe send request only when TTL expired or target address doesn't respond will be better.

@fernvenue commented on GitHub (Aug 28, 2022): By the way, here's another problem, does frp have cache for DNS? ![screenshot](https://user-images.githubusercontent.com/84565547/187056148-f9e0a484-3bda-49ab-b5f2-8191b18bb8b2.png) My DNS server got 166000+ requests from frp just in 7 days, I don't know why frp need this, send requests for every connection is a terrible idea I think, can't we use cache? Or maybe send request only when TTL expired or target address doesn't respond will be better.

gitea-mirror commented

2026-05-05 13:35:13 -06:00

Author

Owner

Copy link

@fatedier commented on GitHub (Aug 28, 2022):

frp uses golang standard net package to do dns resolve. The behavior is same with most other golang programs.

If you want to control your dns resolver, maybe you can try to use some local dns resolver to optimize.

@fatedier commented on GitHub (Aug 28, 2022): frp uses golang standard net package to do dns resolve. The behavior is same with most other golang programs. If you want to control your dns resolver, maybe you can try to use some local dns resolver to optimize.

gitea-mirror commented

2026-05-05 13:35:14 -06:00

Author

Owner

Copy link

@github-actions[bot] commented on GitHub (Sep 28, 2022):

Issues go stale after 30d of inactivity. Stale issues rot after an additional 7d of inactivity and eventually close.

@github-actions[bot] commented on GitHub (Sep 28, 2022): Issues go stale after 30d of inactivity. Stale issues rot after an additional 7d of inactivity and eventually close.

No Branch/Tag specified