Description
On Windows, I ran into a compatibility issue that looks related to the combination of fake-ip DNS mode and DIRECT rules for some Microsoft / Outlook targets.
This does not necessarily look like a core bug in FlClash itself, but it seems like a case where a small compatibility hint, FAQ note, or optional preset could save users a lot of debugging time.
Environment
- FlClash on Windows
mixed-port: 7890mode: rule- DNS
enhanced-mode: fake-ip
respect-rules: false- Rules included entries such as:
DST-PORT,993,DIRECTDST-PORT,995,DIRECTDOMAIN-SUFFIX,office.com,DIRECT
Symptoms
For some Microsoft / Outlook related targets, the client-side behavior looked like this:
CONNECT to the local proxy succeeds- but the following TLS handshake fails with
EOF
Observed examples:
office.com:443outlook.office365.com:993outlook.office365.com:995
At the same time, other Microsoft targets such as graph.microsoft.com were working normally.
What I found during debugging
A few observations seemed consistent:
- FlClash DNS (
127.0.0.1:1053) was returning fake-ip results like 198.18.x.x for some of these domains.
- The matching rules were sending the traffic to
DIRECT.
- In that combination, the application side would eventually see TLS
EOF.
A useful control test was:
- If I resolved
office.com / outlook.office365.com to real public IPs first,
- then connected through FlClash while still keeping the original hostname as TLS SNI,
- the TLS handshake succeeded.
That made it look less like a generic TLS or port issue, and more like an interaction between fake-ip DNS and DIRECT handling for these targets.
Workaround that solved it locally
I changed two things:
dns.respect-rules: true- Added the following entries to
fake-ip-filter:
office.com*.office.comoutlook.office365.com*.office365.comlogin.microsoftonline.com*.microsoftonline.com*.live.com*.msn.com
After that, these tests started working normally through FlClash:
office.com:443outlook.office365.com:993outlook.office365.com:995
Suggestion
I am not sure this should be treated as a code bug, but it may be worth considering one or more of the following:
- add a short FAQ / documentation note for this pattern
- add a warning for common
fake-ip + DIRECT conflict cases
- provide an optional Microsoft / Outlook compatibility preset
- or otherwise surface that
respect-rules: false may be problematic for some DIRECT destinations
If useful, I can also provide a smaller reproduction config and the exact test steps I used.
Description
On Windows, I ran into a compatibility issue that looks related to the combination of
fake-ipDNS mode andDIRECTrules for some Microsoft / Outlook targets.This does not necessarily look like a core bug in FlClash itself, but it seems like a case where a small compatibility hint, FAQ note, or optional preset could save users a lot of debugging time.
Environment
mixed-port: 7890mode: ruleenhanced-mode: fake-iprespect-rules: falseDST-PORT,993,DIRECTDST-PORT,995,DIRECTDOMAIN-SUFFIX,office.com,DIRECTSymptoms
For some Microsoft / Outlook related targets, the client-side behavior looked like this:
CONNECTto the local proxy succeedsEOFObserved examples:
office.com:443outlook.office365.com:993outlook.office365.com:995At the same time, other Microsoft targets such as
graph.microsoft.comwere working normally.What I found during debugging
A few observations seemed consistent:
127.0.0.1:1053) was returning fake-ip results like198.18.x.xfor some of these domains.DIRECT.EOF.A useful control test was:
office.com/outlook.office365.comto real public IPs first,That made it look less like a generic TLS or port issue, and more like an interaction between fake-ip DNS and
DIRECThandling for these targets.Workaround that solved it locally
I changed two things:
dns.respect-rules: truefake-ip-filter:office.com*.office.comoutlook.office365.com*.office365.comlogin.microsoftonline.com*.microsoftonline.com*.live.com*.msn.comAfter that, these tests started working normally through FlClash:
office.com:443outlook.office365.com:993outlook.office365.com:995Suggestion
I am not sure this should be treated as a code bug, but it may be worth considering one or more of the following:
fake-ip + DIRECTconflict casesrespect-rules: falsemay be problematic for someDIRECTdestinationsIf useful, I can also provide a smaller reproduction config and the exact test steps I used.