[Bug] Proxy + IPv6 [::] binding prevents GUI dynamic fields from appearing

Start in the legacy 1.x GUI launch path and locate the bind_addresses definition shown in the report. Reproduce the startup-events failure with HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, and NO_PROXY enabled, then verify the GUI uses the proxy-safe IPv4 loopback first and that service-dependent fields appear. Confirm the existing interactive translation flow still works.

Scope note: this report is specifically about the legacy 1.x GUI implementation in PDFMathTranslate/PDFMathTranslate. I did not reproduce it against PDFMathTranslate-next because its GUI/configuration implementation has been rewritten. I am reporting it here so other 1.x users behind a proxy can find the cause and workaround.

Environment

• OS: Windows 11
• Python: 3.12.14
• pdf2zh: 1.9.12
• Gradio: 5.35.0
• Commit: f4522dd
• Installation: source
• HTTP_PROXY, HTTPS_PROXY, and ALL_PROXY are enabled
• NO_PROXY=localhost,127.0.0.1,::1

Description

The Web UI opens, but dynamic GUI callbacks do not work. For example, selecting DeepSeek in the Service dropdown does not reveal the DEEPSEEK_API_KEY and DEEPSEEK_MODEL fields.

The legacy GUI tries to bind to [::] before IPv4 addresses. Gradio then checks:

http://[::]:7860/gradio_api/startup-events

With the proxy environment described above, that request is routed through the proxy and returns HTTP 502. A browser page may still be served, but Gradio startup events do not complete, leaving dropdown-dependent components stuck or invisible.

This is consistent with the failure mode described in gradio-app/gradio#10729.

Steps to reproduce

1. On Windows, enable an HTTP proxy through HTTP_PROXY, HTTPS_PROXY, and/or ALL_PROXY.

2. Keep the common local bypass value NO_PROXY=localhost,127.0.0.1,::1.

3. Start the GUI:

   pdf2zh --interactive --serverport 7860
   

4. Open the generated Web UI.

5. Select DeepSeek from Service.

6. Observe that the API key/model fields do not appear and the event remains pending.

A minimal Gradio launch using server_name="[::]" reproduces the startup check failure with:

Couldn't start the app because 'http://[::]:7860/gradio_api/startup-events' failed (code 502)

Expected behavior

The local GUI should bind to a proxy-safe loopback address, and selecting a service should immediately update its configuration fields.

Root cause

The current 1.x binding order prefers the IPv6 wildcard:

bind_addresses = []
if _has_ipv6():
    bind_addresses.append("[::]")
bind_addresses.append("0.0.0.0")
bind_addresses.append("127.0.0.1")

Many proxy configurations bypass 127.0.0.1 but do not correctly bypass wildcard/bracketed IPv6 URLs.

Confirmed local fix

Prefer IPv4 loopback for the local interactive GUI:

bind_addresses = ["127.0.0.1", "0.0.0.0"]
if _has_ipv6():
    bind_addresses.append("[::]")

After this change the GUI launches at http://127.0.0.1:7860, the DeepSeek fields appear, and a 14-page translation completes successfully through the configured DeepSeek service.

References

• Project FAQ already notes that global proxy mode can prevent Gradio from starting: https://github.com/PDFMathTranslate/PDFMathTranslate/wiki/FAQ---%E5%B8%B8%E8%A7%81%E9%97%AE%E9%A2%98
• Related Gradio startup-events behavior: https://github.com/gradio-app/gradio/issues/10729